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PREFACE 


This manual describes the elements, including optional user facilities, of CCITT 
Recommendation X.25 -— INTERFACE BETWEEN DATA TERMINAL EQUIPMENT CDTE) AND DATA CIRCUIT 
TERMINATING EQUIPMENT CDCE) FOR TERMINALS OPERATING IN THE PACKET MODE ON PUBLIC DATA 
NETWORKS (Geneva, 1976; amended Geneva, 1980) - that are applicable to IBM SNA network 
nodes that can attach to X.25-based Packet-Switched Data Networks (PSDNs) 


Note: This third edition continues to be based on CCITT Recommendation X.25 as 


published in the ‘Yellow Book’ instead of the ‘Red Book’ version, adopted by the 
VIIIth Plenary Assembly in 1984. 


Excerpts from CCITT Recommendation X.25 (Geneva, November 1980), including sections 
1.1 - 2, 2.1 - 2.4 (Cexcept LAP procedures), -3.1 - 3.5, 4.1 - 4.6, 6.1 - 6.3, 
6.5 - 6.8, 7.1 - 7.2, 7.4 Cexcept Datagrams), Annex A Cexcept Datagrams)}, Annex B, 
Annex C, Annex D and Annex E are reprinted in this manual. 


IBM SNA data terminal equipment (DTEs) that use the X.25 recommendation to interface 
to PSDN data circuit-terminating equipment C(CDCEs) are referred to in this document as 
IBM SNA X.25 DTEs. Elements of CCITT Recommendation X.25 (1980) are selected by IBM to 
support two basic categories of connections: 


a. SNA-to-SNA: 


connections between SNA X.25 DTEs, via virtual calls or permanent virtual 
circuits, or both, are accommodated through intervening packet-ssttched data 
network(s). 


b. SNA-to-non_SNA: 


connections between SNA X.25 DTEs and non-SNA X.25 DTEs, via virtual calls or 
permanent virtual circuits, or both, are accommodated through intervening 
packet-switched data network(s). 


The DTE/DCE interfaces for SNA-to-SNA connections and SNA-to-non_SNA connections 
differ only at the packet level; therefore, the definitions and descriptions of the 
physical level and the link level apply equally to both types of connections. 


Information in this manual must not be construed as describing any specific IBM 
product (machine or program) or service. Neither can it be construed to mean that all 
or any specific IBM products necessarily provide only, or all of, the X¥.25 DTE/DCE 
interface functions described herein. 


In ‘addition, note that the ELLC, @QLLC and PSH Protocols defined in this manual 
describe existing implementations of end-to-end control functions that are required 
above the X.25 DTE/DCE Interface. Further end-to-end controls applicable fer use with 
X.25-based network services may be implemented as requirements become more clearly 
identified. Readers are cautioned to refer to appropriate IBM product description and 
operation manuals for information regarding the availability and characteristics of 
X.25 DTE/DCE interface functions supported by specific IBM products. 


The reader is assumed to be conversant with both CCITT Recommendation X.25 and SNA. A 
list of applicable references is included, at the end of part I, to help the less 
informed reader to understand these subjects. 
This manual is composed of two parts: 

PART I - contains an overview of the relationship between SNA and X.25; and, 


PART II - is patterned after excerpts from CCITT Recommendation X.25 (Geneva, 
November 1980) with modifications identified as noted in the introduction to Part 
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PART I 


This part presents an overview of the relationships that exist between SNA and X.25 
composed of: 


Chapter 1, “INTRODUCTION,” which briefly describes the evolution of CCITT 
Recommendation X.25, IBM's statement of direction relative to its support and the 
evolution of IBM's support . | 


Chapter 2, "ARCHITECTURAL CONSIDERATIONS," which states the architectural 
relationships between SNA and X.25; it also states the SNA assumptions upon which 
IBM X.25 support is predicated. | 


Chapter 3, "X.25 ELEMENTS IN IBM SNA X.25 DTEs,"™ which describes the basic 
elements of CCITT Recommendation X.25 selected by IBM for SNA-to-SNA connections 
and for SNA-to-non_SNA connections using virtual circuit services provided by 
X.25-based PSDNs. 


Chapter 4, "OTHER SYSTEM CONSIDERATIONS," which briefly describes security, 


reliability, availability and serviceability as they relate to the operation of 
SNA in PSDN environments. 
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SNA/X.25 DTE/DCE Interface 


1.0 INTRODUCTION 


Maturing packet-switching technology continues to gain acceptance among 
Telecommunications Administrations, as well as information processing communities, 
throughout the world during the nineteen-eighties. Packet-switched data network 
services are now available for public use in numerous countries and several such 
networks are being operated for private use by corporate enterprises and government 
agencies. PSDNs are currently being installed in both the public and private sectors 
tall the world and still others are being planned to begin operations within the 
ecade. 


1,1 EVOLUTION OF THE X.25 DTE/DCE INTERFACE 


The International Telegraph and Telephone Consultative Committee (CCITT) has 
developed Recommendation X.25 to facilitate attachment of customer data terminal 
equipment to public PSDNs. It was first adopted® at the CCITT VIIth Plenary Assembly 
in 1976 to provide a "standard" interface between customer-provided data terminal 
equipment (CDTE) and public PSDN data circuit-terminating equipment (DCE) Ccommonly 
referred to as the X.25 DTE/DCE interface). 


In 1978, updates contained in a provisional recommendation’? were approved by the 
CCITT. A revised version! incorporates additional enhancements approved by the CCITT 
plenary assembly at Geneva in November of 1980. 


Numerous Telecommunications Administrations, Recognized Private Operating Agencies 
CRPOAS) and Common Carriers have either implemented, or published plans to implement, 
PSDNs with DTE/DCE interfaces based on CCITT Recommendation X.25. Some of these are 
summarized in Table I-1 based on information publicly available as of December 1984. 
Several private PSDNs have also adopted versions of the X.25 DTE/DCE interface as a 
method of attachment. 


Increasing numbers of users of public and private PSDNs specify DTEs that are capable 
of attaching via X.25 DTE/DCE interfaces. They desire vendor-independent, common 
attachment interfaces such that DTEs of one vendor can communicate effectively with 
DTEs of other vendors through public or private PSDNs, or both 


Elements of the X.25 DTE/DCE interface can help to meet the former requirement. They 
enable DTEs to connect to PSDNs, to establish connectivity to other DTEs through one 
or more PSDNs and to transfer data packets from one DTE to the other. While such 
connectivity is essential to effective communication, it cannot be assumed that simply 
because two devices can connect to a PSDN via the X.25 DIE/DCE interface that they can 
communicate with each other in any useful way. 


Effective communication between DTEs requires additional protocols at one or more 
levels above the packet level of the X.25 DTE/DCE interface. Efforts are currently 
being made within the standards community to develop a standard networking protocol, 
referred to as Open Systems Interconnection (0S5SI), to meet the needs of such higher 
levels. These efforts are taking place within the International Organization for 
Standardization (1IS0)*, the International Telephone and Telegraph Consultative 
Committee CCCITT)*, the European Computer Manufacturers Association (ECMA)5, the 
Institute of Electrical and Electronic Engineers (IEEE)* and various’ other 
organizations. 


The ISQ has published a Basic Reference Model for OSI*. The protocols that allow 
effective communication between diverse IBM SNA X.25 DTEs such as data processing, 
distributed computing and office systems are provided by the higher levels of SNA. 

Reference 15 describes some relationships that exist between SNA?*,27°%,274,25,2° and the 
ISO Basic Reference Model for OSI*. Analyses®,’,77,°5° have shown that X.25 DTE/DCE 
interfaces specified for various public and eae PSDNs generally differ to some 
extent. Such differences have been attributed to differing implementation time frames 
or interpretations of the Recommendation, or both. Such diversity has been recognized 
by the Common Carriers, Administrations and Recognized Private Operating Agencies 
CRPOAS). Efforts by some of these organizations to minimize such differences by 
generally agreeing to implement a less permissive X.25 Recommendation!,’,!°,2! has, 
thus far, met with limited success. Thus, it can be anticipated that, as X.25 
continues to evolve, network specific differences in interface definition will 
probably continue for the foreseeable future. 
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CCITT Recommendation X.25 has continued to evolve during the 1980-1984 plenary period 
and additional functional capabilities have been adopted. IBM anticipates, however, 
that such additional capabilities will not impair the operation of DTE implementations 
based on the version of CCITT Recommendation X. 25 adopted by the VIIth Plenary 
Assembly at Geneva in November 1980 and published in the "Yellow Book" and that are 
reflected in this manual. Additional capabilities adopted for CCITT Recommendation 
X.25 by the VIIIth Plenary Assembly are being evaluated to ascertain their 
applicability to DTEs in SNA environments and decisions regarding support of such 
additional capabilities will be based on future business and technical considerations. 


Tabie I-1: Some Pians and Implementations for Networks offering 
| X.25 Interfaces 


Country _ | | Network. | Availability 


ARGENTINA 
AUSTRALIA 


TRANSPAC 
DATEX—P 
HONG KONG | | CWNET 
| aa DATAPAC 
INDONESIA : PACKSATNET 


DACOM-NET 
LUXEMBURG . oe LUXPAC 
MALAYSIA MAYPAC | 
MEXICO TELEPAC 
NETHERLANDS DATANET—1 
NEW ZEALAND — PSN | 
NORWAY DATAPAK 
PORTUGAL PKTNET 
SINGAPORE , TELEPAC 
SOUTH AFRICA : SAPONET 

CTNEX25 
SWEDEN : :  DATAPAK 
SWITZERLAND : TELEPAC 
TAIWAN | Yr 
UNITED KINGDOM , 
UNITED STATES of AMERICA — 


YUGOSLAVIA 


This table is an illustrative reference only. It reflects some of the 
information publicly available as of December 1984 which will doubt— 
less change as X.25 network plans mature and implementations progress. 


1.2 een OF DIRECTION ~ 


In May of 1980 IBM made ake eallouitns public giaasnGendne sieut its use of CCITT 
Recommendations X.21 and X. 25: 


"IBM encourages the use of international standards as the basis for interfaces to 
public data networks providing circuit-switched, packet-switched and leased-circuit 
services. IBM continues to participate in and contribute to international standards 
efforts to develop and enhance these interfaces. Services with interfaces based on 
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CCITT Recommendations X.21 and X.25 provide users with new alternatives’ for 
transmission that supplement the functions provided by IBM's Systems Network 
Architecture (SNA), and should be made available to IBM's customers. 


"It i products to public data networks with X.21 and X.25 interfaces. For example, in 
accordance with IBM's 1978 statement of Direction regarding X.21, IBM announced in 
December 1979 the capability of attaching certain SNA products to Nippon Telegraph and 
Telephone's leased-circuit and circuit-switched X.21l-based services in Japan. IBM has 
also released product adaptations that permit certain products to utilize X.25-based 
services in Canada, France, the Federal Republic of Germany and the Netherlands!’7,?&® 
(The first of these X.25 product adaptations was announced in 1977.] 


"Announcement of attachment capability supporting additional products or functions, 
or for other public data networks with X.21 or X.25 interfaces, will be based on IBM's 
technical and business judgement in addressing the requirements of its customers." 


1.3 EVOLUTION OF IBM X.21 AND X.25 INTERFACES 


In 1980, an X.21 general information manual was published'*. It describes the CCITT 
Recommendation X.21 interface to public data networks (PDNs) as implemented in data 
terminal equipment by IBM. Included are: 


e A brief overview of CCITT Recommendation X.21 


° Information on the functional, mechanical, and electrical characteristics 
specified in CCITT Recommendation X.21 


e Information on the operation of both the circuit-switched and leased-circuit 
network service interfaces defined in CCITT Recommendation X.21. 


IBM also announced in 1980, for certain products, support of X.21 circuit-switched 
services in Denmark, Finland, Norway and Sweden. 


Since May of 1980 IBM has announced X.25 capability for numerous products to attach to 
many different PSDN's around the world. 


CCITT Recommendation X.25 defines three levels of the DTE/DCE interface that PSDNs use 
as a design guide for X.25-based services: 


1. Physical Level -—- the mechanical, electrical, functional and procedural 
characteristics to activate, maintain and deactivate the physical link between the 
DTE and the DCE. 


2. Link Level — the link access procedure for the interchange of data across the link 
between the DTE and the DCE. 


3. Packet Level —- the packet format and control procedures for the exchange of 
packets containing control information and user data between the DTE and the DCE. 


CCITT Recommendation X.25 describes the three levels and the range of services that 
may be provided by PSDNs from the perspective of the DCE. This manual provides 
information on the three levels of CCITT Recommendation X.25 (1980) and describes 
architectural and design choices made by IBM to meet the requirements of its 
customers from the perspective of IBM SNA X.25 DTEs. : 


The services, functions, facilities, and parameter ranges described herein for IBM SNA 
X.25 DTE's are based on reference 1, the revised X.25 Recommendation approved by the 
CCITT plenary assembly at Geneva in November, 1980. 


This X.25 general information manual expounds further on IBM's use of elements of X.25 
at all three levels. It addresses only those elements required to support connections 
between IBM SNA X.25 DTE's and other X.25 DTE's (SNA or non-SNA) using virtual call and 
permanent virtual circuit services provided by PSDNs. It does not address direct 
DTE-to-DTE connections without an intervening PSDN; nor does it address IBM SNA X.25 
nodes functioning as DCEs. 


IBM support of other X.25-related recommendations, such as packet 
assembly/disassembly (PAD) functions’,'!%, are beyond the scope of this manual. 
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2.0 ARCHITECTURAL CONSIDERATIONS 


Packet-switched data network services can provide an efficient and economical method 
for transporting information in some instances. However, application requirements, — 
geographical considerations and applicable tariffs often dictate the use of other 

services and facilities for transporting information. Virtual circuit (VCs) are, | 
therefore, integrated into SNA so as not to preclude concurrent use of other services 
and facilities offered by Communication Carriers, Telecommunications Administrations | 
and Recognized Private Operating Agencies (RPOAS) around the world. : | 


Because of the pervasiveness of X.25 DTE/DCE interfaces, IBM encourages common 
interpretation and implementation to the fullest extent possible. This document 
advances this goal by describing the elements deemed necessary to support two basic 
categories of connections: : 


SNA-to-SNA Connections that allow IBM SNA X.25 DTEs to be connected to each 
other via virtual call or permanent virtual circuit services, or both; and, 


e° SNA-to-non_SNA Connections that allow IBM SNA X.25 DTEs to be connected to 
non-SNA DTEs via virtual call or permanent virtual circuit services, or both. 


It describes architectural directions for both categories of connections but focuses | 
primarily on the elements of CCITT Recommendation X.25 (1980) required to support 
SNA-to-SNA connections. 


2.1 SNA-TO-SNA CONNECTIONS 


One objective of Systems Network Architecture is to afford users the broadest possible 
range of telecommunications services and facilities to meet their requirements. 
Figure 1 depicts some of the data transmission services and facilities available to 
SNA customers in various parts of the world. 


SNA NODE SNA NODE 
H | DL¢ kk ————— Leased Analog Lines ————>|pt¢| 
A 
— Public Switched 
L DLC f<-—— Analog Telephone —————> 
—= Lines 
F P ! P 
—_ A Leased A 
T | DL¢ kk Digital Data ——————>|p1¢| T 
— S H Circuits H 3 = 
— E Cc Switched | C E-— 
0 Cs «Digital Data > pic 0 
eee : Circuits | N es 
T 
ae: R Privately—Owned R a 
0 DLC -<_———— Pacilities ———_———>p1¢| 0 
— J L | L I-— 
_ DLC | 
DLC r<-———————"—— System/370 Channels -—> 
— N N 
— 5S % Packet—Switched ¥ S 
Dic f¢ —————— Virtual Circuit --> 
Services 


¥ — This DLC (Data Link Control) contains Logical Link Control (LLC) and Virtual 
Circuit Protocol (VCP) components, described in the text. 


Figure 1. Coexistence of Data Transmission Services and Facilities: within SNA 
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Computer network architectures, in general, provide for the interconnection of 
physically distributed functions via various types of data transmission facilities. 
Such directly connected nodes are termed ‘adjacent’ within SNA. The Data Link Control 
ney elements provide the protocols used to transfer information between adjacent SNA 
nodes. 


Some SNA nodes, such as clusters and terminals!®, attach to only one adjacent SNA node 
via a single real link. Such single-link nodes are treated as single-virtual-circuit 
X.25 nodes as shown in Figure 2 on page I-6. SNA nodes that can connect to multiple 
SNA adjacent nodes over different physical links, or multi-drop links, are treated as 
multiple point-to-point virtual-circuit connections as shown in Figure 3 an page I-/7. 
In the multi-access configuration, SNA nodes have the capability of ccennecting to 
multiple SNA adjacent nodes using multiple virtual circuits via one or more X.25 
DTE/DCE interfaces. 


SNA nodes interconnected by virtual circuit services remain logically adjacent and the 
X.25 virtual circuit protocol (VCP) provides the mechanism to transfer information 
between these adjacent network nodes. Therefore, virtual circuits serve similar 
functions in the system as other data transmission services and facilities and 
naturally appear at the same architectural level. 


This natural structure provides for the coexistence of the various data transmission 
services and facilities, as well as a desirable multiplexing capability. For example, 
all traffic flowing between adjacent network nodes is readily multiplexed onto a 
single facility. 


To permit concurrent use of data link control and virtual circuit protocol services, 
all of the properties of the former must be available in the latter. IBM SNA X.25 DTEs 
employ Logical Link Control (LLC) protocols to provide certain adjacent node services 
and optionally, to enhance the quality of service exhibited by underlying network 
services, tn environments where SNA nodes are connected through one or more PSDNs. 
These protocols are known as QLLC, which uses 'Qualified'’ data packets to transfer 
data link control information between the two SNA nodes, and ELLC which employs LLC 
headers carried in the user data field of data packets to provide optional circuit 
assurance and data integrity capabilities. Once data link connectivity has been 
established, SNA Path Information Units (PIUs)** are transferred in normal, 
unqualified data packets. PIUs that exceed the maximum user data area of the data 
a are transferred as packet sequences concatenated by the More Data Mark ('M' 
bit). 


Note: Some initial IBM SNA X.25 DTE implementations do not support the QLLC, ELLC and 
"™* bit procedures. They perform adjacent node services and 
segmentation/concatenation using a Physical Services Header (PSH)2%. All IBM SNA X.25 
DTES may not support the Enhanced Logical Link Control (CELLC) procedures. 


It is not an objective to restrict any actual implementations of the X.25 DTE/DCE 
interface functions within IBM products to the elements described here. Network 
specific options may impose additional requirements that must be met to make specific 
IBM SNA X.25 DTEs viable in some countries. Decisions to support national options are 
whee technical and business considerations that are beyond the scope of this 
marual. 
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Figure 2. Real Links Become X.25 Virtual Circuits: for SNA-to-SNA Connections 
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Figure 3. X.25 Multi-Access: for SNA-to-SNA Connections 


2.2 SNA-TO-NON SNA CONNECTIONS 


SNA-to-non_SNA connections provide a mechanism for the exchange of data between an 
application program that resides in an SNA node and a remote non-SNA terminal. For 
example, remote non-SNA terminals can be non-SNA X.25 DTEs or start/stop terminals 
attached to a packet assembly/disassembly (PAD) PSDN facility as defined by CCITT 
Recommendations X.3, *.28 and X.29. Three types of operation defined for 
SNA-to-non_SNA connections are mapped, transparent and hybrid. No standard protocol 
is assumed above the packet level af CCITT Recommendation X.25 for SNA-to-non_SNA 
connections. Higher level protocols remain a matter to be agreed upon between the 
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tah non-SNaA terminal and the supporting application program within the SNA 
network. | 


2.c.1 Mapped Operation 


Mapped operation allows X.25 packet level protocols to be mapped to and from similar 
SNA protocol subsets directly at the SNA X.25 DTE/DCE interface. Thus, virtual 
circuits can be mapped to SNA sessions, ona one for one basis, as depicted in Figure 4 
on page [-9. A host application program can communicate with the non-SNA without any 
X.25 sensitivity. However, the application and the remote node must each understand 
the data streams being exchansed and process them accordingly. 


e.c.c Transparent Operation 


In transparent operation, X.25 packet level protocols can be implemented in an 
application program Coutside the structure of SNA). In this case, the X.25 packet 
level protocols are transported, transparently, within SNA between the application 
ice ae the X.25 DTE/DCE interface and SNA sessions can support one or more 
virtual calls. 


2.2.3 Hybrid Operation 


In hybrid operation, X.25 packet level protocols are neither fully mapped nor fully 
transparent. <A host application program may perform some X.25 packet level functions 
as in transparent operation while the remaining X.25 packet level functions are 
performed at the SNA X.25 interface. 
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Figure 4. One-to-One Session Mapping to Virtual Circuits: for SNA-to-non_SNA 
Connections 


2.3 MULTIPLE DTE/DCE INTERFACES 


Some IBM SNA X.25 DTEs can support multiple X.25 DTE/DCE interfaces. To do so 1s a 
product-specific choice based on traffic requirements and the need to directly access 
two or more networks concurrently. 


Some optional user facilities Ce.g., modulo 128 packet sequence numbering) require an 
X.25 DTE/DCE interface that is separate from the interface that supports the normal 
facility (e.g., modulo 8 packet sequence numbering). : 

Each X.25 DTE/DCE interface is assumed to correspond to a unique address agreed upon. 
with the network Administration. 
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3.0 X.25 ELEMENTS IN IBM SNA X.25 DTES 


The sitenenks: of CCITT Rucommendat ten: X. 251 selected for use in ‘IBM SNA x. 25 DTEs are 
described in this section. Physical level, link level and packet level interfaces are 
addressed. End-to-end protocols that reside at one or more levels above the packet 
level are not described. 


SNA-to-SNA and SNA-to-non_SNA connections differ only at the packet level. Therefore; 
descriptions of the physical level and the link level are common to both types of 
connections. 


Tables contained in subsequent sections use the following terminology: 
All - for functions provided by all IBM SNA X.25 DTEs. 


Some - for functions that may be provided by selected IBM SNA X.25 DTEs to meet 
specific functional requirements and marketing objectives. 


None - for functions normally not provided by IBM SNA X.25 DTEs. 


3.1 PHYSICAL LEVEL 


A summary of IBM SNA X.25 DTE physical level characteristics is provided in Table I-2. 
During an interim period, described in reference 1, IBM SNA X.25 DTEs use CCITT 
Recommendation X.21_bis® for non-switched circuits. However, some IBM SNA X.25 DTEs 
also support the X.21 interface!*,!°%,!% for non-switched circuits; it will become the 
primary support at the end of the interim period. 


At speeds of 19.2 kilobits per second (kbit/s) and below, IBM X.21_bis implementations 
conform to CCITT Recommendation V.24!! with V.28!! electrical characteristics. At 
signaling speeds in excess of 19.2 eee IBM X. SP ana implementations conform to 
CCITT Recommendation V.351!. Some products may provide other non-X.21 interfaces as 
required for attachment to specific network services. : 


All links operate duplex (two-way simultaneous) at one or more of the X.25 speeds 
listed in Table I-2. The particular speed or speeds supported by IBM SNA X.25 DTEs is 
product specific. Some IBM SNA X.25 DTEsS may also support one or more of the 
additional speeds shown in Table I-2. X.21 switched and X.21_bis switched are not 
used at the physical level of the X.25 DTE/DCE interface by IBM SNA X.25 DTEs. 


Table 1-2: Summary of Physical | IBM SNA 
Level Characteristics | 7 X.25 DTEs 


X.21 Switched 
X.21_bis Switched 
X.21 Non-Switched 
X.21_bis Non-Switched 


Duplex Transmission Facility 


X.25 Speeds ~— 2.4 kbit/s 
4.8 " 


Additional Speeds — 1.2 kbit/s 
19.2 


* During the interim period, after which X.21 will be required 
and X.21_bis will be optional | 
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3.2 LINK LEVEL 


CCITT Recommendation X.25 defines two link access procedures (LAP and LAPB) for the 
link level. IBM SNA X.25 DTEs use the balanced procedure, LAPB. The symmetrical 
procedure, LAP, is used only by certain early IBM DTE implementations but will not be 
used in new IBM SNA X.25 DTE implementations. 


The IBM SNA X.25 DTE link level is required to be compatible with the DCE link level as 
defined in reference 1. Thus, certain choices and clarifications of the balanced 
Procedure are required for DTEs. These are given, for IBM SNA X.25 DTEs, below: 


1. The information field of all I-frames transferred across the DTE/DCE Interface 
must contain an integral number of octets Ceight-bit bytes). 


2. IBM SNA X.25 DTEs do not generate the Idle Channel State as a normal sequence. 


3. IBM SNA X.25 DTEs detect but do not, necessarily, consider the Idle Channel State 
to be an error condition; they may assume that the DCE has temporarily suspended 
transmission. 


4. IBM SNA X.25 DTEs support modulo '8' sequence numbering; modulo '128' sequence 
numbering is not used at the link level, since this option its not provided for by 
CCITT Recommendation X.25 (Geneva, November 1980)!. 


5. IBM SNA X.25 DTEs that implement supervisory and unnumbered commands transmit all 
such commands with the poll (P) bit set to one. 


6. Ypon receipt of a command frame with the poll bit set to one, IBM SNA X.25 DTEs set 
the final (F) bit to one in the next response frame transmitted. 


7. Exceptional conditions may be reported by IBM SNA X.25 DTEs to the DCE using the 
FRAME REJECT CFRMR) response as defined in reference 1. They maintain the frame 
rajection condition until it is reset by the DCE or until higher level DTE 
recovery 1s initiated locally. 


8. IBM SNA X.25 DTEs, upon receipt of a FRMR response, are responsible for returning 
the link to operational mode by initiating a link resetting procedure. However, 
to assure synchronization, initiation of the link resetting procedure may be 
preceded by a link disconnection procedure. 


9. After receiving a RECEIVE NOT READY CRNR) frame, IBM SNA X.25 DTEs wait until 
receipt of a RECEIVE READY (RR) or REJECT CREJ) frame before transmitting 
additional information (CI) frames unless or until the Link resetting procedure is 
completed. During this period of time, they will send an RR or RNR command frame 
in order to ascertain the status of the DCE. 


10. Information (I) frames contain only one packet each. 
11. IBM SNA X.25 DTEs may employ a nested time-out function to avoid prematurely 


declaring link/stations inoperative because of transient errors on the 
transmission link. 


3.3 PACKET LEVEL 


The packet level elements are considered for two categories of connections via PSDNs, 
SNA-to-SNA and SNA-to-non_SNA. 


3.3.1 SNA-tO-SNA Connections 


The IBM SNA X.25 DTE packet level is required to be compatible with the DCE packet 
level as defined in reference 1. This section gives the packet level elements 
required for SNA-to-SNA communication, and defines how IBM SNA X.25 DTEs use the 
packet level procedures, formats, and facilities in clarification of reference 1. 


SNA-to-SNA communication 18 via virtual call (VC) or permanent virtual circuit (PVC) 


services, or both. Datagram services are not used. A given SNA X.25 DTE may contain 
virtual call capability or permanent virtual circujt capability, or both. Table I-3 
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lists the packet types used on SNA-to-SNA connections that affect given virtual calls 
CVC) and given permanent virtual circuits (PVC) and that affect all VCs and PVC at the 
X.25 DTE/DCE interface (I/F}. Table 1-4 lists the packet types that are not used on 
SNA-to-SNA connections. ; _ | 


Table I-3: Packet Types Used by IBM SNA X.25 DTEs eae 
on SNA-to-SNA Connections* SER 
PACKET TYPES 


ACCEPTED —- INCOMING CALL 

CALL CONNECTED 

CLEAR INDICATION 

DCE CLEAR CONFIRMATION 
DCE DATA 

DCE RECEIVE READY 

DCE RECEIVE NOT READY 
RESET INDICATION 

DCE RESET CONFIRMATION 
RESTART INDICATION 

DCE RESTART CONFIRMATION 
DIAGNOSTIC 


CALL REQUEST 
CALL ACCEPTED 

CLEAR REQUEST 

DTE CLEAR CONFIRMATION 
DTE DATA 

DTE RECEIVE READY 

DTE RECEIVE NOT READY 
RESET REQUEST | 
DTE RESET CONFIRMATION 
RESTART REQUEST 

DTE RESTART CONFIRMATION 


VC — Affects given Virtual Calls 
PVC —- Affects given Permanent Virtual Circuits 
I/F — Affects all VCs and PVCs at the DTE/DCE Interface 


x«x «KKK KKK 


TRANSMITTED — 


KK WK KEK OK OK OOK OOK 


* All packet types are not necessarily used by all IBM SNA X.25 DTEs 


Table I-4: Packet Types Not Used by IBM SNA X.25 DTEs 
on SNA-to-SNA Connections 


PACKET TYPES 


NOT ACCEPTED —- DCE INTERRUPT 
DCE INTERRUPT CONFIRMATION 


DCE DATAGRAM 
DATAGRAM SERVICE SIGNAL 


NOT TRANSMITTED — DTE INTERRUPT 
DTE INTERRUPT CONFIRMATION 
DTE DATAGRAM 
DTE REJECT 


3.3.1.1 Initialization 


The packet level DTE/DCE interface is initialized before virtual call and permanent 
virtual circuit procedures begin. IBM SNA X.25 DTEs execute the DTE restart procedure 
after link level initialization is complete. The X.25 DTE/DCE interface becomes 
operational upon successful completion of the restart procedure. The restart 
procedure 1s used after normal link level activation and after Link level failure 
recovery for packet level initialization. 
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3.3.1.2 Data Transfer 

Data is exchanged between IBM SNA X.25 DTEs using virtual calls or permanent virtual 
circuits, or both. IBM SNA X.25 DTEs may transmit: 

1. DTE DATA 

2. DTE RECEIVE READY and 

3. DTE RECEIVE NOT READY packets. 

They accept and respond to: 

1. DCE DATA 

2. DCE RECEIVE READY and 

3. DCE RECEIVE NOT READY packets. 


These packets are used as described in reference 1 except as noted in this section. 
DTE REJECT (CREJ) packets are not used. 


The characteristics of data packets used on SNA-to-SNA connections are summarized in’ 
Table I-5. 


Table I-5: Characteristics of Data Packets Exchanged IBM SNA 
on SNA-to-SNA Connections X.25 DTEs 
Qualifier Bit, "Q = 0° All 
"Q = 1° Al1l* 
Delivery Confirmation Bit, "D = 0° All 
'D = 1" None 
Packet Sequence Numbering, Modulo "8" All 
Modulo '128' Some 
More Data Bit, 'M = 1 transmitted All * 
7M = 1" accepted Al1* 
User Data Fields Contain Integral Number of Octets Only 
Maximum User Data Length = 128 Octets All 
= 16, 32, 64, 256, 512 or 1024 Octets Some | 
Window Size = '1' < 'Wt < "8" (Modulo '8') All 
<€< '128" (Modulo '128!) Some 


¥ Some IBM SNA X.25 DTE implementations do not support the QLLC, ELLC 
and 'M® bit procedures. They perform adjacent node services and 
segmentation/concatenation using Physical Services Headers. 


DTEs that use PSHs and do not accept 'M = 1° require the maximum 
User Data field sizes at the local and remote DTE/DCE interfaces 
to be identical. 


The Qualifier bit "Q=1" is transmitted by IBM SNA X.25 DTEs to identify Logical Link 


OORT OE (LLC) information. The Delivery Confirmation bit 'D=1" is not used by IBM SNA 
F TEs. 


All IBM SNA X.25 DTEs allow modulo '8' packet sequence numbering; some may also allow 
modulo '128' packet sequence numbering. 


IBM SNA X.25 DTEs use the More Data Mark (M-bit) for packet. sequence generation and 


interpret the 'M' bit on received packets to properly reassemble received packet 
sequences. 


IBM SNA X.25 DTEs, which require user data to be an integral number of octets, 
accommodate a maximum user data field length of '128' octets. Window sizes, W, of 
1<sW< 8 are used for modulo '8' packet sequence numbering. Window sizes, W, of 
1 <¢ W < 128 are used for modulo '128' packet sequence numbering. 
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Some IBM SNA X.25 DTEs may also allow optional maximum User Data fields of "16° 9 S32 52: 
"64", "256", "512", or "1024! octets. 7 


3.3.1.3 Call Control 


For control of virtual calls, IBM SNA X.25 DTEs may transmit: 
1. CALL REQUEST 

2. CALL ACCEPTED 

3. CLEAR REQUEST and 

4. DTE CLEAR CONFIRMATION packets. 

They may accept and respond to: | 

1. INCOMING CALL 

2. CALL CONNECTED 

3. CLEAR INDICATION and 

4. DCE CLEAR CONFIRMATION packets. 


Call control packets are used as described in reference 1. Clarifications for the use 
of call control Packers on SNA to- SNA connections are summarized in Table I-6. 


Table I-6: Use of Call Control Packets on SNA-to-SNA | IBM SNA | 
Connections. X.25 DTEs j} 


General Format Identifier 


User option to specify Calling DTE Address in 
Z CALL REQUEST 


Facilities Field in — CALL REQUEST 
INCOMING CALL 
CALL ACCEPTED 
CALL CONNECTED 


Call User Data (CUD) Field in — CALL REQUEST and 
INCOMING CALL 


Calling and Called DTE Address length field in : 
| CALL ACCEPTED 


DTE Originated Diagnostic Code in CLEAR REQUEST 
~ CLEAR INDICATION 


The General Format Identifier (GFI) is encoded "0001" for modulo '8" packet sequence 
numbering, or '0010' when extended packet sequence numbering is used. 


The first octet of the Call User Data field isa Protocol Identifier (see §-6.2.1.6, in 
part II) that has particular significance and is required. In addition to the 
network-specific significance specified in CCITT Recommendation X.25 for bits 8 and 7, 
IBM SNA X.25 DTEs use: 


bit 2 to distinguish between SNA-to-SNA connections and SNA-to-non_ SNA 
connections that may coexist at the same DTE/DCE interface; and, - 


e bit 3 to specify the particular logical link control to be used on SNA- to-SNA 
connections. | 


IBM SNA X.25 DTEs set the contents of the Clearing Cause field to x'00° and ieee a 


diagnostic code in CLEAR REQUEST packets for delivery, by PSDNs, to partner DTEs in 
CLEAR INDICATION packets. | : | 
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IBM SNA X.25 DTEs may optionally supply a Calling DTE address in CALL REQUEST packets. 
The facilities field in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, and CALL CONNECTED 
packets may be used to specify optional user facilities. 


Some optional user facilities require explicit support functions to be provided by 
DTEs; others, designated "User Choice’, do not. Table I-7 summarizes those facilities 
that are available with all, some or none of the IBM SNA X.25 DTEs on SNA-to-SNA 
connections. ‘User choice’ means that availability of the facility is not dependent 
upon any explicit support functions in IBM SNA X.25 DTEs; support for the facility 15 
provided entirely on the DCE side of the X.25 DTE/DCE interface. 


When subscribed optional user facilities are indicated in INCOMING CALL packets, IBM 
SNA X.25 DTEsS may analyze the facility parameter field and either: 


Accept the call with no further comment in CALL ACCEPTED packets. 
e Negotiate using the facility field in CALL ACCEPTED packets. 


e Reject the call using CLEAR REQUEST packets with an appropriate diagnostic 
Indication. 


IBM SNA X.25 DTEs may reject calls that tndicate unsubscribed optional user facilities 
in INCOMING CALL packets by issuing a CLEAR REQUEST packet with an appropriate code in 
the diagnostic field. 


All IBM SNA X.25 DTEs detect national facility marker(s) indicated in INCOMING CALL 
packets. Some may also recognize and act upon non-X.25 facilities. 


Table I-7: Optional User Facilities IBM SNA 
for SNA-to-SNA Connections X.25 DTEs 


Nonstandard Default Packet Sizes 

Nonstandard Default Window Sizes 

Default Throughput Classes Assignment 

Incoming Calls Barred 

Outgoing Calls Barred 

Single Closed User Group 

Single Closed User Group with Outgoing Access 
Single Closed User Group with Incoming Access 
Incoming Calls Barred Within a Closed User Group 
Outgoing Calls Barred Within a Closed User Group 
Reverse Charging Acceptance 

One-Way Logical Channel Qutgoing 

One-Way Logical Channel Incoming 

Reverse Charging 

Flow Control Parameter Negotiation 

Throughput Class Negotiation 

Multiple Closed User Groups 

Multiple Closed User Groups with Outgoing Access 
Multiple Closed User Groups with Incoming Access 
Extended Packet Sequence Numbering 

RPOA Selection 

Fast Select 

Fast Select Acceptance 

Packet Retransmission 

Bilateral Closed User Group 

Bilateral Closed User Groups with Outgoing Access 


3.3.1.4 Error Notification in the Data Transfer Phase 

During the data transfer phase, IBM SNA X.25 DTEs convey Error Notifications across 
the DTE/DCE interface in the Cause and Diagnostic Code fields of: 

1. CLEAR REQUEST 

2. RESET REQUEST and 

3. RESTART REQUEST packets. 
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They process error notification information received from DCEs in the Cause and 
Diagnostic Code fields of: 


1. CLEAR INDICATION 
2. RESET INDICATION and 
3. RESTART INDICATION packets. 


Contents of Diagnostic Code and Diagnostic Explanation fields of DIAGNOSTIC packets 
area used for error notification. 


These packet types are used as described under “Initialization” on page I-12 after 
link level activation and for error notification. Errors detected by DCEs are 
described in reference 1. Errors detected by IBM SNA X.25 DTEs are indicated in the 
Diagnostic Code field of CLEAR REQUEST, RESET REQUEST or RESTART REQUEST packets for 
delivery, by PSDNs, to affected remote DTEs in CLEAR INDICATION, RESET INDICATION and 
RESTART INDICATION packets. Table I-8 provides clarifications for the use of error 
notification packets on SNA-to-SNA connections. 


Table I-8: IBM SNA X.25 DTE Use of Error Notification IBM SNA 
Packets on SNA-to-SNA Connections X.25 DTEs 


General Format Identifier (GFI) in all packets = b'OOO0L' All 
| = b'0010' Some 


Clearing Cause Field in CLEAR REQUEST packets = x'00' 


Resetting Cause Field in RESET REQUEST packets = x'00' All 
Restarting Cause Field in RESTART REQUEST packets = x'00'° All 


Diagnostic Code Field in CLEAR, RESET and RESTART REQUEST | ALL | 


3.3.1.5 Actions of the DTE in Unusual Circumstances 


Ll. DTE Time-Outs 


After issuing a CALL REQUEST, CLEAR REQUEST, RESET REQUEST and RESTART REQUEST, 
IBM SNA X.25 DTEs start a time-out. This timer jis reset upon receipt of the 
corresponding confirmation packet from the DCE. 


If the time-out expires prior to receipt of the corresponding confirmation packet 
from the DCE, IBM SNA X.25 DTEs may retransmit the request packet and restart the 
timer. This retransmission procedure may occur "n20! times. If the 
retransmission procedure is not successful, the failure is reported to the higher 
levels of SNA. 


2. DTE-Detected Errors 
Errors detected by IBM SNA X.25 DTEs are categorized as follows: 


I - those that result from receipt of unsupported packet types (e.g., DCE 
INTERRUPT or DCE DATAGRAM packets). 


II - those that can result from discrepancies between the DTE and DCE 
interpretations of the state of some subscribed interface parameter. 
Ce.g., receipt of an INCOMING CALL packet on a logical channel assigned 
for permanent virtual circuit service). 


III - those most likely resulting from a malfunction of the DCE (e.g., 
receipt of an unsolicited DCE RESTART CONFIRMATION packet). 


I¥V - those caused by failures at the physical level or the link level 
Ce.g., dropping of the Data Set Ready indication). 


For category 'I' and 'II' errors, IBM SNA X.25 DTEs clear the virtual call or reset 
the permanent virtual circuit if such an action 1s permitted without violating any 
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procedure. The error condition is reported to the higher levels of SNA; the 
received packet ts discarded. 


For category ‘'III" errors, IBM SNA X.25 DTEs transmit a RESTART REQUEST packet 
across the DTE/DCE interface, place all virtual circuits in an inoperative state 
and report the error condition to the higher levels of SNA 


For category 'iV' errors, IBM SNA X.25 DTEs place the LAPB link and all the virtual 
circutts at the DTE/DCE interface in an inoperative state and report an interface 
failure to the higher levels of SNA. 


3. DCE-Detected Errors 


DCEs indicate detected error types in the Cause and Diagnostic Code fields of 
RESET INDICATION, CLEAR INDICATION and RESTART INDICATION packets and in the 
Diagnostic Code and Diagnostic Explanation fields of DIAGNOSTIC packets. 


IBM SNA X.25 DTEs act as a function of the severity of the situation, taking into 
account the Call Progress Signal descriptions provided in CCITT Recommendation 
X.96. When the response to a CALL REQUEST is a CLEAR INDICATION with a cause field 
of severity Dl or D2 Cas defined in CCITT Recommendation X.96) and in the case of 
local procedure errors, IBM SNA X.25 DTEs report the contents of the Clearing 
Cause and Diagnostic Code fields to higher levels of SNA and await further 
Instructions. When a RESET or CLEAR INDICATION is received during the data 
transfer phase, a virtual call is cleared and the virtual circuit is placed in an 
inoperative state, unless successful recovery is effected at the ELLC level. 
Contents of the Clearing Cause and Diagnostic Code fields are reported to higher 
levels of SNA. When a RESTART INDICATION packet is received, all of the virtual 
circuits of the DTE/DCE interface are placed in-:-an inoperative state unless 
successful recovery is effected at the ELLC level. Contents of the restarting 
Cause and Diagnostic Code fields are reported to higher levels. When a DIAGNOSTIC 
packet is received, contents of the Diagnostic Code and Explanation fields are 
reported to higher levels. No logical channel state changes occur as a result of 
receiving DIAGNOSTIC packets. 


4. Unsuccessful Calls 


DCEs tndicate that virtual calls cannot be completed by inserting the appropriate 
codes itn the Clearing Cause and Diagnostic Code fields of CLEAR INDICATION 
packets. When these codes tndicate network congestion, out-of-order or number 
busy, IBM SNA X.25 DTEs either retry the operation or refer the retry to a higher 
level. The number of retries may be a system generation parameter for DTEs. 


‘3.3.2 SNA-to-non SNA Connections 


On SNA-to-non_SNA connections, the X.25 packet level functions, formats and facilities 
supported are defined by the application program as a function of the requirements of 
the non-SNA X.25 DTE. 


In transparent operation, IBM SNA X.25 DTEs may elect to accept and transmit all 
packet formats defined in CCITT Recommendation X.25, except DTE REJECT, DATAGRAM and 
DATAGRAM SERVICE. SIGNAL packets. 


3.3.2.1 Packet Types 


The packet types shown in Table I-9 may be allowed on SNA-to-non_SNA connections In 
addition to those shown in Table I-3. 
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Table I-9: Additional Packet Types Available on 
SNA-to-non_SNA Connections 


PACKET TYPES 


ACCEPTED -— DCE INTERRUPT 
—- DCE INTERRUPT CONFIRMATION 


TRANSMITTED — DTE INTERRUPT 
—- DTE INTERRUPT CONFIRMATION 


VC — Affects given Virtual Calls 
PVC —- Affects given Permanent Virtual Circuits 
I/F — Affects all VCs and PYCs at the DTE/DCE Interface 


The characteristics of data and call control packets used for SNA-to-non_SNA 
connecticns are as summarized in Tables I-5 and I-6, respectively, for SNA-to-SNA 
connections, except that the Delivery Confirmation ('D' bit) procedure may be used hy 
some DTEs on SNA-to-non_SNA connections. 


3.3.2.2 Use of Call Control Packets 


The first octet of the Call User Data field (called the Protocol Identifier (PI)) in 
CALL REQUEST packets is used to distinguish packets on SNA-to-SNA connections from 
those on SNA-to-non_SNA connections at a given SNA X.25 DTE/DCE Interface. The 
setting of bits 8» 7 and 2 to ‘'l's in the first octet of the Call User Data field 
indicates an SNA-to-SNA connection. 


Codings of the first octet of the Call User Data field in which bits 8 and 7 are set to 
"1's and bit 2 is set to '0" indicates an SNA-to-non_SNA connection. 


3.3.2.3 Error Notification 


The coding of the Diagnostic Code field in RESTART REQUEST, CLEAR REQUEST and RESET 
REQUEST packets is not standardized for SNA-to-non_SNA connections. Therefore, IBM 
SNA X.25 DTEs do not assign any value to this field. However, they do accept and pass, 
to higher levels, diagnostic codes set by partner D7Es. 
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4.0 OTHER SYSTEM CONSIDERATIONS 
4.1 SECURITY 


6.1.1 SNA-to-SNA Connections 


Called DTEs can implement a rudimentary calling DTE identification check by testing 
the calling DTE address in INCOMING CALL packets. DTEs can elect to implement as a 
user option a connection identification capability defined for CALL REQUEST and 
INCOMING CALL packets. 


Care must be exercised in choosing cryptographic techniques. Data link control level 
cryptographic products defined for SNA products cannot be used at the X.25 link and 
packet levels. Cryptographic products defined for SNA above, and transparent to, the 
data link control level can be used. 


64.1.2 SNA-to-non SNA Connections 


Security techniques are specific to the particular non-SNA remote DTE being supported. 
In general, techniques used for SNA-to-SNA connections are not applicable. 


6.2. RELIABILITY, AVAILABILITY AND SERVICEABILITY (RAS) 


‘Errors at the X.25 DTE/DCE interface, either detected by IBM SNA X.25 DTEs or 
indicated by their associated DCEs, are reported to the SNA control point or to a local 
operator, as appropriate. The network-generated Cause and Diagnostic Codes defined in 
CCITT Recommendation X.25, and a common set of DTE-originated diagnostic codes defined 
for SNA-to-SNA connections, are used for reporting purposes to aid in problem 
determination. Session outage notifications are propagated in accordance with general 
SNA mechanisms pertaining to link/station fatlures. | 
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PART II 


CCITT Recommendation X.25 (Geneva, November 1980) defines an interface between 
customer data terminal equipment (DTE) and data circuit-terminating equipment (DCE). 
It 1s designed to facilitate the attachment of DTEs to packet-switched data networks 
(PSDNs). The definition includes three independent elements: , 


1. Physical Level - the mechanical, electrical, functional and procedural 
characteristics to activate, maintain and deactivate physical communication links 
between DTEs and DCEs. 


2. tink Level - the link access procedure for the interchange of data across 
communication links between DTEs and DCEs. 


3. Packet Level - the packet formats and control procedures for the exthunge of 
control information and user data, or both, between DTEs and DCEs. 


Other international standards explicitly or implicitly setarenced in this 
document include: 


a. CCITT Recommendation X.1 - International User Classes of Service in Public 
Data Networks. 


b. CCITT Recommendation X.2 - International User Services and Facilities in 
Public Data Networks. | | 


c. CCITT Recommendation X.21 - Interface between Data Terminal Equipment (DTE) 
and Data Circuit-Terminating Equipment (DCE) for synchronous PRES ELON on 
Public Data Networks. 


d. CCITT Recommendation X.21_bis - Use on Public Data Networks of Data Terminal 
Equipment (DTE) which are Designed for Interfacing to aynenrgneue V-Series 
Modems. 


e. CCITT Recommendation X.96 - Call Progress Signals in Public Data Networks. 


f. CCITT Recommendation X.110 - Routing Principles for International Public Data 
Services through Switched Public Data Networks of the Same Type. 


g. CCITT Recommendation X.121 - International Numbering Plan for Public Data 
Networks. 


CCITT Recommendation X.25 focuses on a description of the DTE/DCE Interface functions 
from the perspective of DCEs. This manual focuses on the same interface from the 
perspective of DTEs. Thus, several instances occur where the term DTE or DCE 1s 
replaced by the word station(s). Other substantive differences between the two 
interface descriptions are identified by vertical bars (|) in the left margin of this 
manual. Text in this edition of the manual that has been changed or extended for 
clarification or to. correct errors found in the second edition, as well as that 
required to accommodate and describe the enhanced logical link control PRereees 15 
identified by the figure '2' in the left margin. 


Note: 


1. The bit/byte numbering used throughout this manual is consistent with the 
numbering used in CCITT Recommendation X.25 (1980) and may, therefore, differ from 
that with which the reader may be more familiar. 


2. Network specific interface requirements, that deviate from the interpretation of 
CCITT Recommendation X.25 (Geneva, November 1980) reflected in this document, may 
be considered by IBM SNA X.25 Product Managers on an individual basis, in making 
technical and business judgements regarding possible justification for the 
support of such deviation(s). Network specific interface requirements are not 
defined in this manual. 


This part describes the X.25 DTE/DCE Interface as perceived by IBM SNA X.25 DTEs, 
based on CCITT Recommendation X.25 as published in the ‘Yellow Book!’ instead of the 
version adopted by the VIIIth Plenary Assembly in 1984 to be published in the ‘Red 


Book® sometime in 1985, and is composed of nine sections and several appendices as 
~ollows: 


PART II ~TI- 


Section 1 - DTE/DCE Interface Characteristics - specifies the physical level 
interface used between IBM SNA X.25 DTEs and their associated DCEs. 


Section 2 - Link Access Procedure Across the DTE/DCE Interface - specifies the 
link level interface used for the interchange of data via communication links 
between IBM SNA X.25 DTEs and their associated DCEs. 


Section 3 - Description of the Packet Level DTE/DCE Interface - describes the 
packet level procedures used to exchange control information and user data at the 
X.25 DTE/DCE interface. 


Section 4 - Procedures for Virtual Circuit Services - describes the procedures 
used for virtual call and permanent virtual circuit services. 


aoc een 5 ~ Procedures for Datagram Services - is not applicable for IBM SNA X.25 
TEs. 


Section 6 - Packet Formats - specifies the formats for packets exchanged between 
IBM SNA X.25 DTEs and their associated DCEs. 


Section 7 - Procedures and Formats for Optional User Facilities - specifies the 
optional user facilities allowed by IBM SNA X.25 DTEs and the procedures and 
formats for their selection and use. 


Section 8 - Logical Link Control (CLLCO) on SNA-to-SNA Connections - defines the 
format and use of 'Qualified' data packets to perform adjacent SNA node physical 
services. 


Section 9 - Other System Considerations - describes some other considerations for 
the use of IBM SNA X.25 DTEs in Packet-Switched Data Network environments. 


Appendix A - defines the range of logical channels used for virtual calls and 
permanent virtual circuits. 


Appendix B - defines the states of the packet level at the X.25 DTE/DCE interface. 


Appendix C - describes the actions taken by DCEs on receipt ef packets ina given 
state of the packet level X.25 DTE/DCE interface as perceived by DCEs. 


Appendix D - defines packet level DCE time-outs and DTE time-limits. 


Appendix E - specifies the diagnostic codes generated by DCEs employing CCITT 
Recommendation X.25 for CLEAR, RESET INDICATION, RESTART INDICATION and 
DIAGNOSTIC packets. 


Appendix F - specifies the diagnostic codes generated by IBM SNA X.25 DTEs for 
CLEAR REQUEST, RESET REQUEST and RESTART REQUEST packets on SNA-to-SNA 
connections. 


Appendix G - describes the actions taken by IBM SNA X.25 DTEs on receipt of 
packets ina given state of the packet level of the X.25 DTE/DCE interface as 
perceived by DTEs. 


Appendix H - describes the Physical Services Header (PSH) used on SNA-to-SNA 
connecticns to an IBM 5973 Network Interface Adapter (NIA). | 


Appendix I - describes some architectural considerations for SNA-to-non SNA 
connections. 


Appendix J - describes the actions taken by IBM SNA X.25 DTEs upon occurrence of 
events in the various states of the link layer interface. 


Appendix K - describes the formats, protocols and procedures employed by IBM SNA 


X.25 DTEs for an enhanced logical link control between adjacent nodes on 
SNA-to-SNA connections. 
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SNA/X.25 DTE/DCE Interface 


1.6 DTE/DCE INTERFACE CHARACTERISTICS - (PHYSICAL LEVEL) 


The DTE/DCE physical interface characteristics defined as the Physical Level element 
shall be in accordance with CCITT Recommendation X.21l. For an interim period, some 
‘Common Carriers, Administrations or Recognized Private Operating Agencies (RPOAsS) may 
offer a DTE/DCE interface at this level in accordance with Recommendation X.21 bis. 
The exact use of the relevant points in these Recommendations is detailed in the 
following points of this specification. 


X.21 and X.21 bis as defined in CCITT Recommendations V.24 and V.35 for leased service 
only are used. 


1.2 DEDICATED ACCESS 


The interface characteristics for DTEs connected to packet-switched data transmission 
services by dedicated circuits are described in "X.21 Interface” through "X.21_bis 
Imterface. 


1.3.1 xX.21 Interface 


1.4.1.1 Elements 


The DTE/DCE physical interface elements shall be according to $8-2 of CCITT 
Recommendation X.21. 


1.1.1.2 Test Loops 


The operation of test loops shall be according to §-7 of CCITT Recommendation X.21. 


1.3.1.3 Procedures 


The procedures for entering operational phases shall be as follows: 


1. when the DTE signals 'c=0N', signals on circuit ‘'T' shall be according to the 
higher level procedures described in the following points of this Specification. 


2. when the DCE signals ‘'i=ON', signals on circuit 'R* shall be according to the 
higher level procedures described in the following points of this Specification. 


3. the DTE/DCE interface should normally remain in the operational condition with 
both "c=ON" and 'i=ON' to enable proper operation of the higher level procedures 
described in the following points of this Specification. 


4. if a situation necessitates the DTE to signal DTE ready or DTE uncontrolled not 
ready, or the DCE to signal DCE ready or DCE not ready, the interface should return 
to the operational condition with both '‘c=O0ON" and ‘'i=ON' when the situation is 
appropriate to enable normal operation of the higher level procedures described in 
the following points of this Specification. 


lil.2 X.21 bis Interface 


DITE/DCE-Interface-Characteristics---(physical-level) II-1 


SNA/X.25 DTE/DCE Interface 
1.1.2.1 Elements 


The DTE/DCE physical interface elements shall be according to §-1 of CCITT 
Recommendation X.21_bis. . | 7 | | —_ 


1.1.2.2 Problem Determination. 
Failure detection and fault isolation shall be according to §-3 of CCITT 
Recommendation X.21_bis. os <f - 


Note: - The addition of circuit #142 (Test) is considered a future requirement for 
IBM SNA X.25 DTEs. 


1.1.2.3 Procedures 


When circuits 105, 106, 107, 108 and 109 are in the 'ON' condition, signals on circuits 
103 and 104 shall be according to the higher level procedures described in the 
following points of this specification. 


i.2 SWITCHED ACCESS 


The interface characteristics and procedures for DTEs connected to packet-switched 
data transmission services through circuit-switched data transmission services are 
not allowed in SNA environments. 


(Text deleted). 


1.3 ACCESS SPEEDS 
IBM SNA X.25 DTEs support one or more of the following CCITT recommended data 
transmission speeds: 

2.4%, 4.8, 9.6 or 48.0 Kbit/s. 


Additional data transmission speeds that may be considered by specific IBM SNA X.25 
DTEs include: 


1.2, 19.2, 56.6 and 64.0 Kbit/s. 
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2.0 LINK ACCESS PROCEDURE ACROSS THE DTE/DCE INTERFACE 
2.1 SCOPE AND FIELD OF APPLICATION 


2.1.1 The Link Access Procedure (LAPB) (text deleted) 


LAPB is described as the Link Level Element used for the interchange of data between 
DCEs, operating in user classes of service 8 to 11 as indicated in CCITT 
Recommendation X.1, and IBM SNA X.25 DTEs. 


2.1.2 Principles and Terminology 


The procedure uses the principle and terminology of the High Level Data Link Control 
(HDLC) procedures specified by the International Organization for Standardization 
CISO}. 


2.1.3 The transmission facility is duplex, 


2.1.4 IS0 Compatibility 


Station CDCE and DTE) compatibility of operation with the ISO balanced class of 
procedure (Class BA, options 2 and 8) is achieved using the provisions found under the 
headings annotated as CLAPB) in this specification. 


(Text deleted. ) 


Note: Other possible applications being considered by the CCITT include: 


e (Text deleted. ) 
© - two-way alternate, normal response mode. 


2.2 FRAME STRUCTURE 


2.2.1 Format 


All transmissions across the X.25 DTE/DCE interface are in frames conforming to one of 
the formats shown in Table II-1. The flag preceding the address field is defined as 
the opening flag. The flag following the Frame Checking Sequence (FCS) is defined as 
the closing flag. 


2.c.¢ Flag (F) Sequence 


All frames shall start and end with at least one flag sequence consisting of at least 
one '0* bit followed by six contiguous '1' bits and at least one "0° bit €'01111110'). 
A single flag sequence may be used as both the closing flag for one frame and the 
opening flag for the next frame. IBM SNA X.25 DTEs transmit and receive bit 
configurations '...0111111001111110..." as flag sequences and receive and interpret 
bit configurations *"...011111101111110...' as flag sequences. 
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2.2.3 Address (A) Field 


The A field 15 a single octet, positioned as shown in Table II-1 and coded as described 
in "Procedure for Addressing (Text deleted)" on page JI-14. | 


2.2e-% Control (Cc) Field 


The C field is a single octet, positioned as shown in Table II-1 whose content is 
described in "Control Field Formats and State Variables" on page IJI-6. | 


Note: Possible extension of the control field is being considered by the CCITT. 


| TABLE II-1 — Frame Formats | | 


Order of Bit 
Transmission 12345678 12345678 12345678 16 to 1 12345678 


[Fias _| Address] contro] Fos | Flas 


FCS 
a | c¢ FCS a 
01111110] 8-bits | 8-bits | 16—-bits 101111110 


' Transmission 12345678 12345678 12345678 123.......n 16 to 1 12345678 


Order of Bit 


ries 
cS 


F 
F A C Ir F F 
01111110] 8-bits | 8-bits | N-Octets* [16—bits/01111110 


FCS = frame checking sequence 
¥ — Octet is an 8-bit byte. 


2.2.5 Information (1) Field 


The I-field of all frames transmitted and received by IBM SNA X.25 DTEs must contain an 
integral number of octets and is unrestricted with respect to code or grouping except 
for the packet formats specified in "PACKET FORMATS” on page I1I-46, the 'Qualified' 
data packet formats for SNA-to-SNA connections shown in "Logical Link Control (LLC) on 
SNA-to-SNA Connections” on page II-83 and the Physical Services Header (PSH) formats 
for SNA-to-SNA connections described in Appendix H. : 


Note: Frames containing other than an integral number of octets are ignored by IBM 
SNA X.25 DTEs at the link level. | | 


See "(Text deleted); Frame Reject (FRMR) Response™ on page II-11 and "Maximum Number 
of Bits in an I-frame, N1" on page II-23 below with regard to the maximum information 
field length. 


2.2.6 Transparency — 


Transmitting stations examine the frame content between the two flags including the 
address, control, information and FCS and insert a '0! bit immediately following all 
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sequences of 5 contiguous "1" bits Cincluding the last 5 bits of the FCS) to ensure 
that a flag is not simulated by data on the line. Receiving stations examine the frame 
content and discard any '0' bit that immediately follows 5 contiguous '1' bits. 


2.c./ Frame Checking Sequence (FCS) 


The FCS is a 16-bit sequence containing the ones complement of the sum (modulo 2) of: 


1. The remainder of Xk(X!5 + X25 4+ xX?53 + 1... + X27 + X + :1) divided (modulo 2) by the 
generator polynomial X!®©° + X!2 + X5 + 1, where k is the number of bits in the frame 
existing between, but not including, the final bit of the opening flag and the 
first bit of the FCS, excluding bits inserted for transparency, and 


2. the remainder after multiplication by X!° and then division (modulo 2) by the 
generator polynomial X!®& + X!2 + X5 + 1, of the content of the frame, existing 
between but not including, the final bit of the opening flag and the first bit of 
the FCS, excluding bits inserted for transparency. 


As a typical implementation, at transmitting stations, the tnitial remainder of the 
diviston is preset to all ones and is then modified by division by the generator 
polynomial (Cas described above) on the address, control and information fields; the 
ones complement of the resulting remainder is transmitted as the 16-bit FCS. 

At receiving stations, the initial remainder is preset to all ones, and the serial 
incoming protected bits and the FCS when divided by the generator polynomial will 


result in a remainder of '0001110100001111' (X!5 through X°, respectively) in the 
absence of transmission errors. 


2.c.8 Order of Bit Transmission 


Addresses, commands, responses, sequence numbers and information octets are 
transmitted with the low order bit first (for example the first bit of the sequence 
number that is transmitted has the weight 2°). 


(Text deleted). The FCS shall be transmitted to the line commencing with the 
coefficient of the highest term. 


Note: The low order bit is bit 1, as depicted in Tables II-1 to II-4. 


2.2.9 Invalid frames 


Frames not properly bounded by two flags, or having fewer than 32 bits between flags, 
are invalid. | 


2.2.10 Frame abortion 


A frame being transmitted may be aborted by the transmission of an abortion sequence 
Ce.g., at least seven (7) contiguous ‘'1' bits (with no tnserted '0's)). 


2.2.11 Interframe Time-Fill 


The transmission of contiguous flags between frames is defined as interframe 
time-fill. . 
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-2.2.12 Link Channel States 


2.c-l2.1 Active Channel State 


A channel is ‘active’ when the transmitting station 1s actively transmitting a frame, 
an abortion sequence or interframe time-fill. 


2.2.12.2 Idle Channel State 

A channel is ‘idle’ when a contiguous ‘1's condition is detected, by the receiving 

station, that persists for at least fifteen (15) bit times. 

IBM SNA X.25 DTEs detect the idle channel state and may consider it to be either: 

e an indication that the DCE is not able to support link set-up; 

° a simple indication that the DCE has temporarily suspended transmission; or; 

e an indication that the link is in the disconnected phase if a flag sequence is not 
received within at least time Ti. Ti is defined in "DTE Timer, Ti™ on page II-23. 


Note: 


1. The action to be taken by DCEs upon detection of the idle channel state is a 
subject for further study by the CCITT. 


2. & link channel as defined here is the means of transmission for one direction. 
2.3 ELEMENTS OF PROCEDURE 


2.3.1 Introduction 

The elements of procedure are defined in terms of actions that occur on receipt of 
commands at receiving stations. 

The elements of procedure specified here contain a selection of commands and responses 
relevant to the link and system configuration described itn "Scope and Field of 
Application™ on page II-3. 

A procedure is derived from these elements of procedure and is described in 
"Description of the Procedure" on page II-14. Together "Frame Structure” on page II-3 


and "Elements of Procedure" form the general requirements for proper management of the 
access link connecting DCEs and IBM SNA X.25 DTEs. 


2.3.2 Control Field Formats and State Variables 


2.3.2.1 tcntrol (C} Field Formats 


The C field contains a command or a response, and sequence numbers where applicable. 
Three C-field formats (see Table II-2) are used to perform numbered information 


‘transfers (I-frames), numbered supervisory functions (S-frames) and unnumbered 
control functions (U-frames). | 7 
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TABLE II-2 — Control Field Formats 


transmitter send sequence number (bit 2 = low order bit). 
transmitter receive sequence number (bit 6 = low order bit). 
supervisory function bit. 

modifier function bit. 

poll (P) bit in command frames or final (CF) bit in response 
frames (1 = Poll/Final). 


1. Information Transfer Format — I 


The I format is used to perform information transfers. The functions of Ns, Nr and 
P/F are independent; i.e., each I-frame has an Ns, and an Nr which may or may not 
acknowledge additional I-frames received by the station transmitting the Nr, anda 
P/F bit. 


2. Supervisory Format —- S$ 
The S format jis used to perform link supervisory control functions such as 
acknowledging I-frames, requesting retransmission of I-frames, and requesting 
temporary suspension of transmission of I-frames. 


3. Unnumbered Format — U 


The U format is used to provide additional link control functions. This format 
contains no sequence numbers. 


(Text deleted. ) 


2.3.2.2 Control Field Parameters 


The various parameters associated with the control field formats include a modulus and 
frame variables and sequence numbers. 


2.3.2.3 Modulus 


Each I-frame is sequentially numbered and may have the value 'Ns=0" through 
"Ns=modulus minus one’ (where "modulus”™ jis the modulus of the sequence numbers). The 
modulus equals '8' and the sequence numbers cycle through the entire range '0' to '7', 
inclusive. 


2.3-c-% Frame Variables and Sequence Numbers 


1. Send State Variable 


The send state variable (Vs) denotes the sequence number of the next in-sequence 
I-frame to be transmitted. Vs can take on the value '0' through ‘modulus minus 
one’. The value of Vs is incremented by one with each successive I-frame 
transmission, but at transmitting stations cannot exceed Nr of the last received I 
or S-frame by more than the maximum permissible number of outstanding I-frames 
(K). The value of 'K' is defined in "Maximum Number of Outstanding I-frames, K" on 
page II-23. . 


2. Send Sequence Number 
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Only I-frames contain Ns, the send sequence number of transmitted frames. Prior 
to transmitting an in-sequence I-frame, the value of Ns is set equal to the value 
of Vs at the transmitting station. 


3. Receive State Variable 


The receive state variable (Vr) denotes the sequence number of the next 
in-sequence I-frame to be received at receiving stations. Vr can take on the 
values '0' through "modulus minus one’. The value of Vr is incremented by one upon 
receipt of each error free, in-sequence (with an Ns that 15 equal to the current 
value of Vr at the receiving station) I-frame. 


4. Receive Sequence Number 


All I frames and S-frames contain Nr, the expected sequence number of the next 
received I-frame. Prior to transmitting an I or S-frame, Nr is set equal to the 
current value of Vr at the transmitting station. Nr indicates that the station 
transmitting the Nr has correctly received all I-frames numbered up to and 
including 'Nr-L'. | 


e.3.3 Functions of the Poll/Final Bit 


The poll/final (P/F) bit serves a function in both command frames and response frames. 
In command frames the 'P/F' bit is referred to as the Poll (P) bit. In response frames 
1t 1s referred to as the Final (F) bit. 


Procedures for use of the 'P/F* bit are described in "Procedure for Use of the P/F Bit 
(text deleted)” on page II-14. 


‘2.3.4 Commands and Responses 


Commands and responses transmitted and received by DCEs operating in LAPB mode and IBM 
SNA X.25 DTEs are described in "Information (I) Command" on page II-9 through "(Text 
deleted); Frame Reject (FRMR) Response" on page II-11 and are depicted in Table II-3. 
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TABLE II-3 — Commands and Responses Bits 
8 6 5 4 3 2 1 


7 
Information ~ Nr P/F 
transfer 
Supervisory RR RR Nr P/F 0 
RNR RNR Nr P/F 0 
REJ REJ Nr P/F 1 


(See Note) 


Unnumbered 
(See Note) 


DISC = Disconnect 
DM = Disconnected Mode 
FRMR = Frame Reject 
I = Information 
REJ = Reject 
RNR = Receive Not Ready 
RR = Receive Ready 
SABM = Set Asynchronous Balanced Mode 
UA = Unnumbered Acknowledgement 


All Supervisory and Unnumbered Commands are transmitted by IBM 
SNA X.25 DTEs with 'P=1'; Information transfer frames are 
transmitted by IBM SNA X.25 DTEs with 'P=0". 


| (Text deleted.) 


2.3.4.1 Information (I) Command 


I commands are used to transfer sequentially numbered frames, that contain information 
| fields, across data links connecting X.25 DCEs and IBM SNA X.25 DTEs. 


2.3.4.2 Receive Ready (RR) Command and Response 


RR supervisory frames are used by transmitting stations to: 


1. indicate that they are ready to receive I-frames; 
2. acknowledge previously received I-frames numbered up to and including 'Nr-1’". 


RR frames may be used to clear busy conditions initiated by the transmission of RNR 
frames. RR commands with 'P=1' may be used by transmitting stations to solicit the 
status of remote stations. 


2.3.4.3 Reject (REJ) Command and Response 


REJ supervisory frames are used by transmitting stations to request retransmission of 
I-frames starting with the frame numbered Nr. I-frames numbered 'Nr-1' and below are 
acknowledged. Additional I-frames pending initial transmission may be transmitted 
following the retransmitted I-frame(s). 


Only one REJ exception condition for a given direction of information transfer may be 
established at any time. REJ exception conditions are cleared (reset) upon receipt of 
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an I-frame with an Ns equal to the Nr contained in the REJ frame. REJ commands with 
ats "P=E" may be used by transmitting stations to solicit the status of remote 
stations. | | 


2.3.9.4: Receive Not Ready (RNR) Command and Response 


RNR supervisory frames are used by transmitting stations to indicate busy conditions; 
i.e., temporary inability to accept additional I-frames. I-frames numbered up to and 
including 'Nr-i' are acknowledged. I-frame Nr and subsequent I-frames received, if 
any, are not acknowledged; the acceptance status of these I-frames is indicated tn 
subsequent exchanges. 


Indication that a busy condition at a transmitting station has cleared is communicated 
to the remote station by the transmission of a UA, RR, REJ or SABM. 


RNR commands with the '"P=1' may be used by transmitting stations to solicit the status 
of remote stations. 


Upon receipt of an RNR command or response IBM SNA X.25 DTEs start timer Tp if it is 
not running. It timer Tp then expires prior to the receipt of a UA, RR, REJ or SABM, 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limtts”" on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher level. 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM or UA, notification must be signalled to a higher level to protect 
tne integrity of the system unless ELLC is being used. 


2.3.4.5 Set Asynchronous Response Mode (SARM) Command 


SARM commands are not transmitted, and result in a frame rejection condition when 
received, by IBM SNA X.25 DTEs. 


CText deleted). 


2.3.4.6 Set Asynchronous Balanced Mode (SABM) Command 


Unnumbered SABM commands are used by transmitting stations to place the remote station 
in the asymchronous balanced mode (ABM) information transfer phase. 


No information field is permitted with the SABM command. Receiving stations confirm 
acceptance of SABM commands by transmitting a UA response at the first opportunity. 
Upon acceptance of a SABM command receiving stations set both Vs and Vr equal to 'O'. 
IBM SNA X.25 DTEs always transmit SABM commands with 'P=1'. 


Previously transmitted I-frames that are unacknowledged when a SABM command is 
executed remain unacknowledged (see "Waiting for Acknowledgement" on page [I-19). 


Note: If wnacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM-or UA, unless ELLC is being used, notification must be given toa 
higher level so that the DTE/DCE packet level interface can be restarted to protect 
the integrity of the system. 


2.3.4.7 Bisconnect (DISC) Command 


Unnumbered DISC commands are used by transmitting stations to terminate the 
operatiomal mode previously set. DISC informs the receiving station that the 
transmitting station 1s suspending operation. 
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No information field is permitted with DISC commands. Prior to executing DISC 
commands, receiving stations confirm acceptance by transmitting a UA response. 
Transmitting stations enter the disconnected phase upon receipt of the acknowledging 
GA response. IBM SNA X.25 DTEs always transmit DISC commands with 'P=1'. Previously 
transmitted I-frames that are unacknowledged when the DISC command is executed remain 
unacknowledged (see "Waiting for Acknowledgement" on page II-19). 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM or UA, unless ELLC is being used, notification must be given toa 
higher level so that the DTE/DCE packet level interface can be restarted to protect 
the integrity of the system. 


2.3.4.8  Unnumbered Acknowledgement (UA) Response 


Unnumbered UA responses are used by transmitting stations to acknowledge receipt and 
indicate acceptance of SABM and DISC commands. Receiving stations transmit a UA 
response before executing the received U command. The UA response is transmitted with 
"F=1"' when 'P=1" in the received U command. No information field is permitted with UA 
responses. 


2.3-%.9 Disconnected Mode (DM) Response 


Unnumbered DM responses are used to report a status where the transmitting station is 
logically disconnected from the link, and is in the disconnected phase. The DM 
response may be sent in this phase to request a set mode command, or, if sent in 
response to the receipt of an SABM command, to inform the remote station that the 
transmitting station is still itn disconnected phase and cannot execute the SABM 
command. No information field is permitted with the DM response. 

Stations in the disconnected phase monitor received commands and: 


e react to SABM and DISC commands as described in "Procedures for Link Set-Up and 
Disconnection CLAPB)™ on page JI-15; and, 


° respond DM with 'F=1' to any other command received with 'P=1". 


2.3.4.10 (Text deleted); Frame Reject (FRMR) Response 


(Text deleted) 

FRMR responses are used by stations to report error conditions that are not 
recoverable by retransmission of the identical frame to the remote station; 1.e., one 
of the following conditions, resulting from the receipt of a frame without FCS error: 

e a command or response that 1s invalid or not implemented; 

e an information field that exceeds the maximum permissible length; 

e an invalid Nr (text deleted); or, 

e an information field which is not permitted or an S or U frame of incorrect length. 
An invalid Nr is one that points to an I-frame that has been previously transmitted and 
acknowledged or to an I-frame that has not been transmitted and 1s not the next 
sequential I-frame pending transmission. 

An information field which immediately follows the control field, and consists of 3 


octets, is returned with the (text deleted) FRMR response. This format is shown in 
Table 4. 
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TABLE II—~4 — FRMR Information Field Format 


I-field bits lod1éii41 1 1 1 
2 7 


Rejected Frame 


Control Field 


e Rejected frame control field is the control field of the received frame that 
| caused the (text deleted) frame reject. 


Vs is the current value of Vs at the station reporting the rejection condition 
Cbit 10 = low order bit). 


e Vr is the current value of Vr at the station reporting the rejection condition 
(bit 14 = low order bit). 


® 'W=1" indicates that the control field received and returned in bits 1 through 8 
was considered invalid or not implemented. 


e "X=1'" indicates that the control field received and returned in bits 1 through 8 
was considered invalid because the frame contained an information field which 1s 
not permitted or is an S or U-frame with incorrect length. ‘'W=1' in required in 
conjunction with this bit. 


e "Y=1" indicates that the information field received exceeded the maximum 
established capacity of the station reporting the rejection condition. 


° *Z=1" indicates that the control field received and returned in bits 1 through 8 
contained an invalid Nr. 


|] Note: (Text deleted) Bit 13 is set to: 


"1' if the frame rejected was a response; or, 
"O’ if the frame rejected was a command. 


2.3.5 Exception Condition Reporting and Recover 


Procedures to effect recovery following the detection/occurrence of exception 
conditions at the link level are described in "Busy Condition" through "Rejection 

Condition” on page II-13. Exception conditions described include situations that may 
occur as the result of transmission errors, station malfunctions or abnormal 
operational situations. 


2.3.5.1 Busy Condition 


* busy condition results when a station is temporarily unable to continue receiving 
I-frames due to internal constraints (e.g., receive buffering limitations). 
Notification of the busy condition 1s conveyed to the remote station by transmitting 
an RNR frame across the DTE/DCE interface. I-frames pending transmission may be 
transmitted by stations experiencing a busy condition, either prior to, or following, 
transmission of the RNR frame. Recovery from a busy condition 1s indicated by 
stations as described in "Receive Not Ready (RNR) Command and Response" on page JI-10. 


2.3.5.2 NS Sequence Error 


A sequence exception condition results when an error-free (no FCS error) I-frame with 
an Ns that is not equal to the current value of Vr at the receiving station is 
received. Receiving stations do not acknowledge Cincrement their Vr) I-frames that 
result in sequence exception conditions. 
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The information field of all I-frames received with an Ns that is not equal the current 
value of Vr at the receiving station is discarded. 


Stations that receive one or more I-frames having sequence errors but otherwise 
error-free accept the control information contained in the Nr field and the 'P' bit to 
perform link control functions (e.g., to receive acknowledgement of previously 
transmitted I-frames and to cause the station to respond (C'P=1")). Therefore, 
retransmitted I-frames may contain an Nr field and 'P" bit that are updated, and. 
therefore different from, those contained in the originally transmitted I-frame(s). 


2.3.5.3 REJ Recovery 


REJ frames are transmitted by stations to initiate exception recovery (retransmission) 
following detection of sequence errors. 


Only one "sent REJ" exception condition for a station is estabiished at a time. A 
"sent REJ™ exception condition is cleared when the requested I-frame is received; or, 
when a link set-up or disconnection procedure as described in "Link Set-up" on page 
II-15 or "Link Disconnection" on page II[-16 1s performed. 


Stations receiving REJ initiate sequential Cre-)Jtransmission of I-frames starting 
with the one indicated by the Nr contained in the received REJ frame. 


2.3.5.4 Reply Time-out Recovery 


If,. due to a transmission error, a station does not receive Cor receives and discards) 
a single I-frame or the last I-frame in a sequence of I-frames, it cannot detect an 
out-of-sequence exception condition and will, therefore, fail to transmit REJ. DCEs 
shall, following the completion of a system specified time-out period (see "Time-Outs 
and Time-Limits™ on page II-22), take appropriate recovery action to determine at 
which I-frame retransmission must begin. 


IBM SNA X.25 DTEs use the lost reply protection mechanism, described in "Deadlock 
Protection™ on page I1I-14, after a system specified time-out period (see "Time-Outs 
and Time-Limits™ on page I[I-22), to determine at which I-frame to begin 
retransmission. 


2.3.5.5 FCS Error, Unknown Address and Invalid Frame 


Any frame received with an FCS error, an unknown address (1.e.,other than "A’ or BY) 
or that is invalid (see "Invalid frames" on page II-5) 1s discarded and no action is 
taken by the receiving station as the result of such frame(s). 


2.3.5.6 Rejection Condition 


A rejection condition is established upon receipt of an error-free frame that contains 
an invalid command/response in the C field, an invalid frame format, an invalid Nr 
(text deleted) or an information field that exceeds the maximum information field 
length that can be accommodated. 


Receiving stations report exception conditions to the remote station by transmitting a 
(text deleted) FRMR response. Stations that receive a FRMR response are responsible 
for returning the the link to operational mode by transmitting an SABM command. After 
transmitting a FRMNR response, stations maintain the frame rejection condition until 
reset by the remote station. I-frames received by stations in the frame rejection 
condition are discarded, except for the 'P' bit indication (Nr is ignored). The (text 
deleted) FRMR response may be repeated at each opportunity until recovery 1s effected 
by the remote station, or until internal recovery 1s initiated locally. 
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2.4 DESCRIPTION OF THE PROCEDURE’. 


Tables J-l, -2, -3 and ~-4 in appendix J formalize the actions taken, frames | 
transmitted and state transitions made by DTEs as a result of events Secure ung in the 
various states of the X.25 DTE/DCE Link Level interface. 


2.4.1 Procedure to Set the Mode Variable B (Text Deleted) 
Mode variable procedures are not required in SNA environments since only balanced mode 
CLAPB) procedures are allowed. 


(Text deleted). 


2.4.2 Procedure for Addressing (Text deleted) 


Frames containing commands transferred from: 


DCEs contain the address VAY, 
DTEs contain the address 'B’. 


Frames containing responses transferred from: 


DCEs contain the address 'B’. 
DTEs contain the address ‘'A". 


Addresses, A and B, are coded as follows: 
Address) 87654321 
A 00000011 
B o0000001 


Note: Stations (DCEs and DTEs) discard all frames received with an address other than 
TAY or "BY. . 


2.4.3 Procedure for Use of the P/F Bit (text deleted) 


Upon receipt of any command frame with '‘'P=1', receiving stations transmit an 
appropriate response frame with 'F=l' at the first opportunity (Ce.g.» immediately 
following the frame currently being transmitted, if any). Appropriate responses 
include: | : 

® a UA or DM response to received SABM and DISC command frames; 

e an FRMR, REJ, RNR or RR response to received I-frames; and, 

® an FRMR, RNR or RR response to received supervisory command frames. 


The *"P’ bit ts also used in conjunction with timer recovery conditions as described in 
"Waiting for Acknowledgement" on page II-19. (CText deleted). 


2.4.3.1 Deadlock Protection 


Transmitting stations provide a time-out function to protect against dead-lock 
conditions caused by the loss of responses from the remote station due to transmission 
errors. A timer Tl Cor Tp for DTEs) may be started upon transmission of I-frames or 
supervisory command frames, or both, during the information transfer phase. Timer Tl 
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Cand Tp for DTEs) is also used during link set-up and disconnection as described in 
"Link Set-up” on page II-15 and "Link Disconnection” on page II-16, respectively. 


If timer Tl Cor Tp for DTEs) expires prior to receipt of an appropriate response frame 
from the remote station, recovery action is initiated by the local station. 
Transmitting stations transmit an appropriate supervisory command frame or retransmit 
the appropriate I-frame with 'P=1' and restart timer T1 Cor Tp for DTEs). If timer Tl 
expires prior to receipt of an appropriate response with 'F=1' from the remote station 
N2 times, appropriate recovery action is. initiated by the DCE. 


Upon exptration of timer Tp prior to receipt of an appropriate response with ‘'F=1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits”™ on page II-22 before declaring the link (station) to be tnoperative and 
reporting the condition to a higher layer. 


2.%.% Procedure for Link Set-Up and Disconnection (LAP) 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. (Text 
deleted) 


2.4.5 Procedures for Link Set-Up and Disconnection (LAPB) 


2.4.5.1 Link Set-up 


Stations indicate their ability to set up the link by transmitting contiguous flag 
sequences Cactive channel state). 


Upon receipt of a SABM command, receiving stations prepared to receive I-frames return 
a UA response and set both Vs and Vr equal to '0'. Stations that for some reason are 
unable, or do not desire, to enter the information transfer phase return a DM response 
to received SABM commands. 


DTEs wishing to set-up the link transmit a SABM command with 'P=1" and start timer Tp 
Csee "Deadlock Protection" on page II-14). Upon receipt of a UA response with 'F=1' 
from the DCE, DTEs set both Vs and Vr equal to '0' and stop timer Tp. 


IBM SNA X.25 DTEs should always take the initiative in the link level initialization 
procedure by sending SABM with 'P=l1'. | 


Upon receipt of a DM response with '‘'F=l1' indicating that the DCE cannot accept 
activation of the link, DTEs must report the condition to a higher layer and take no 
further action. 


Upon expiration of timer Tp prior to receipt of an appropriate response with 'F=1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits"™ on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher layer. 


DCEs wishing to set-up the link, transmit a SABM command and start Timer Tl (see 
"Time-Outs and Time-Limits™ on page II-22). Upon reception of a UA response from the 
DTE, DCEs reset both Vs and Vr to '0' and stop Timer Tl. 


Should timer Tl expire before reception of the UA response from the DTE, DCEs 
retransmit the SABM command and restart Timer Tl. After transmission of the SABM 
command N2 times by the DCE, appropriate recovery action is initiated. The value of N2 
1s defined in "Maximum Number of Retransmissions, N2™" on page II-23. 


2.4.5.2 Information Transfer Phase 


Stations, having transmitted a UA response to an received SABM command or having 
received a UA response to a transmitted SABM command, accept and transmit I and 
S-frames according to the procedures described in "Procedures for Information Transfer 
(Text deleted)" on page II-17. 
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Upon recetpt of an SABM command, a UA response or a DM response with 'F=0!, while in 
the information transfer phase, IBM SNA X.25 DTEs conform to the resetting procedure 
described in "Procedures for Resetting (LAPB)" on page II-20. 


When receiving an SABM command while in the information transfer phase, DCEs will 
conform to the resetting procedure described in "Procedures for Resetting CLAPB)"™ on 
page II-20. 


2.4.5.3 Link Disconnection 


During the information transfer phase, stations indicate drscennectrag of the link by 
transmitting a DISC command across the DTE/DCE interface. 


Upon receipt of a DISC command, receiving stations return a UA response and enter the 
disconnected phase. 


DTEs wishing to disconnect the link transmit a DISC command with 'P=1'" and start timer 
Tp (see "Time-Outs and Time-Limits"™ on page II-22). Upon receipt of a UA response with 
*F=1" from the DCE, DTEs stop timer Tp. 


Upon expiration of timer Tp prior to receipt of an appropriate response with 'F=l1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits™ on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher layer. 


Should the DCE wish to disconnect the link, it will send the DISC command and start 
Timer Tl (Csee "Time-Outs and Time-Limits™ on page II-22. Upon receipt of the UA 
response from the DTE, the DCE will stop Timer T1. 


Should Timer T1 expire before reception of the UA response from the DTE, the DCE will 
retransmit the DISC command and restart Timer Tl. After transmission of the DISC 
command N2 times by the DCE, appropriate recovery action will be initiated. The value 
of N2 is defined in "Maximum Number of Retransmissions, N2" on page II-23. 


2.4.5.4 Disconnected Phase 


1. Stations, having received a DISC command and returned a UA response, or having 
received a UA response to a transmitted DISC command, enter the disconnected 
phase. 


Stations, in the disconnected phase, may initiate link set-up. While in the 
disconnected phase, stations react to the receipt of SABM commands as described in 
"Link Set-up” on page II-15 and respond DM received DISC commands. 


pon receipt of any command frame Cother than SABM) with 'P=1', receiving stations 
respond DM with 'F=l1'. 


Upon receipt of a DM with 'F=0", DTEs may transmit an SABM command with 'P=1". 
Other frames are ignored by receiving stations while in the disconnected phase. 


2. When the DCE enters the disconnected phase after detecting error conditions as 
listed in "Rejection Conditions (LAPB)" on page II-21, or exceptionally after 
recovery from a temporary internal malfunction; it may also indicate this by 
sending a DM response rather than a DISC command. In these cases, the DCE will 
transmit DM and start timer Tl Csee "Time-Outs and Time-Limits"” on page II-22). 


If timer Tl runs out before the reception of an SABM or DISC command from the DTE, 
the DCE will retransmit the DM response and restart timer Tl. After transmission 
of the DM response N2 times, DCEs remain in the disconnected phase and initiate 
appropriate recovery actions. The value of N2 is defined in "Maximum Number of 
Retransmissions, N2" on page II-23. | 
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2.4.5.5 Collision of Unnumbered Commands 
Collision situations are resolved in the following manner. 


1. Like Commands when the sent and received U commands are the same, receiving 
stations both send a UA response at the earliest possible opportunity. Stations 
enter the indicated phase upon receipt of the UA response. 


2. Unlike Commands when the sent and received U commands are different, receiving 
stations both enter the disconnected phase and transmit a DM response at the 
earliest possible opportunity. 


2.4.5.6 Collision of a DM Response With a SABM or DISC Command 


When a DM response is issued by the DCE as an unsolicited response to request the DTE 
to issue a mode-setting command, as described in "Disconnected Phase" on page II-16, a 
collision between the SABM or DISC command issued by the DTE and the unsolicited DM 
response issued by the DCE may occur. IBM SNA X.25 DTEs always transmit SABM and DISC 
commands with '"P=1' to avoid misinterpretation of such unsolicited DM responses. 


2.4.6 Procedures for Information Transfer (Text deleted) 


These procedures apply to the transmission of I-frames itn each direction of 
transmission during the information transfer phase. 


In the following text, "number one higher” is in reference to a continuously repeated 


sequence series, i.e., "7' is one higher than '6" and "0" is one higher than '7' for 
modulo eight series. 


2.%.6.1 Sending I Frames 


Stations having I-frames to transmit (Ci.e., I-frames not already transmitted, or 
having to be retransmitted as described in “Receiving Reject™ on page [I-19 or 
"Waiting for Acknowledgement™ on page II-19, transmit them with an Ns equal to the 
current value of Vs at the transmitting station, and an Nr equal to the current value 
of Vr at the transmitting station. Upon completion of transmission of each successive 
I-frame, transmitting stations increment Vs by one (1). 


DCEs start timer Tl if it is not running at the instant of transmission of an I-frame. 


IBM SNA X.25 DTEs must start timer Tp upon completion of transmission of I-frames if it 
1s not already running. : 


When the value of VWs at a transmitting station is equal to the last value of Nr 
received from the remote station plus 'K' (where 'K' is the maximum permissible number 
of outstanding I-frames allowed - see "Maximum Number of Outstanding I-frames, K" on 
page II-23), stations do not transmit any new I-frames, but may retransmit I-frames as 
Se in "Receiving Reject" on page II-19 or "Waiting for Acknowledgement” on page 
II-19. 


Note: To ensure integrity of information transfer, stations do not transmit any 
I-frames when Vs at the transmitting station is equal to the last value of Nr received 
from the remote station plus '7'. 


Stations in the busy condition may continue to transmit I-frames, provided the remote 


station is not also in a busy condition. (Text deleted). Stations in the frame 
rejection condition, do not transmit I-frames. 
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1. Correct Receipt 


Upon receipt of an I-frame with the correct FCS and an Ns equal to the current 
value of Vr at the receiving station, stations not in the busy condition accept 
the I-field, increment the value of Vr by one (1) and acknowledge receipt of the 
I-frame(s) by transmitting: 


a. the next sequential I-frame to be transmitted, if available, or an RR 
supervisory frame with an Nr equal to the current value of Vr; or, 


b. an RR Supervisory frame with an Nr equal to the current value of Vr, if no 
I-frame is available for transmission. 


2. Busy 


DCEs may ignore the information field contained in I-frames received while in a 
~ busy condition. 


DTEs ignore the information field contained in I-frames received while itn a busy 
condition. 


Note: Zero length information fields shall not be passed to the packet level by the’ 
DCE and this situation should be indicated to the packet level. 


IBM SNA X.25 DTEs treat I-frames with zero length information fields the same as any 
other I-frame at the link level. 


2.4.6.3 Receipt of Incorrect Frames 


Frames with an incorrect FCS, an unknown address and invalid frames (see "Invalid 
frames" on page II-5) are ignored by receiving stations. 


Stations receiving I-frames with the correct FCS, but with an incorrect Ns (i.e., one 
that 1s not equal to the current value of Vr at the receiving station) discard the 
I-field and transmit a REJ response with an Nr one higher than the Ns contained in the 
last correctly received I-frame. Then they discard the I-field, but use the Nr and 'P*: 
bit indications of all I frames received with an Ns that is not equal to the eek toe: 
value of Vr at the receiving station. Upon receipt of the expected I-frame (i.e., one 
with an Ns equal to the current value of Vr), receiving stations acknowledge the frame 
as described in "Receiving I-Frames."™ 


2.4.6.4 Receiving Acknonledgement 


DTEs, even in a busy condition (text deleted), consider the Nr contained in correctly 
received I or S (CRR, RNR and REJ) frames to be an acknowledgement for all I-frames 
transmitted with an Ns up to and including 'Nr-1'. 


IBM SNA X.25 DTEs reset timer Tp upon correct receipt of an I or S-frame that actually 
acknowledges some previously transmitted I-frame(s) (i.e., a frame with an Nr higher 
oe value of the last Nr received); or, upon receipt of an I or S-frame with 


If timer Tp has been reset with I-frame(s) still unacknowledged, DTEs restart timer 
Tp. If timer Tp expires prior to receipt of an acknowledgment, DTEs follow the 
retransmission procedure described in "Receiving Reject" on page [I-19 and "Waiting 
for Acknowledgement” on page II-19 with respect to the unacknowledged I-frame(s). 


When correctly receiving an I or S-frame (RR, RNR or REJ), even in the busy Ctext 
deleted) condition, DCEs consider the Nr contained in this frame as an acknowledgment 
for all the I-frames they have transmitted with an Ns up to and including the received 
Nr minus ene. The DCE will reset timer Tl when it correctly receives an I or S-frame 
with the Nr higher than the last received Nr (Cactually acknowledging some I-frame(s)). 
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If. timer Tl has been reset, and if there are outstanding I-frames” still 
unacknowledged, the DCE will restart timer Tl. If timer T1 then runs out, the DCE will 
follow the retransmission procedure Cin "Receiving Reject" on page IJI-19 and "Waiting 
for Acknowledgement" on page II-19) with respect to the unacknowledged I-frames. 


2.4.6.5 Receiving Reject 


Upon receipt of a REJ frame, receiving stations set Vs equal to the Nr contained in the 
received REJ frame, then transmit the corresponding I~frame when it is available or 
retransmit it. 


Stations conform to the following with respect to the re-transmission of I-frames: 


1. <A station that is transmitting a supervisory or unnumbered command or response 
when tt receives a REJ, will complete the transmission in progress’ before 
commencing transmission of the requested I-frame. 


2. A station that is transmitting an I-frame when a REJ is received, may abort 
transmission of the I frame and commence transmission of the requested I-frame 
immediately after abortion. | 


3. A station that is not transmitting any frame when a REJ is received, commence 
transmission of the requested I-frame immediately: 


Other unacknowledged I-frames already transmitted, following the one indicated in the 
REJ- are retransmitted following retransmission of the requested I-frame. 


If the REJ frame was received from the remote station as a command with ‘'P=l1', 
receiving stations transmit an RR or RNR response with 'F=1' prior to transmitting or 
retransmitting the corresponding I-frame. 


2.4.6.6 Receiving RNR 


After receiving an RNR, stations may transmit or retransmit the I-frame with Ns equal 
to the Nr indicated in the RNR frame received. If timer T1 Cor Tp for DTEs) runs out 
after the reception of RNR, stations follow the procedure described in "Waiting for 
Acknowledgement.” Stations do not transmit any other I-frames after receipt of an RNR 
frame until an RR or REJ frame is received from the remote station. 


2.4.6.7 Station Busy Condition 


Stations experiencing a busy condition transmit an RNR command or response at the 
earliest opportunity. While itn the busy condition, stations accept and process 
S-frames and respond RNR with 'F=1' to I and §S command frames received with 'P=1". To 
clear a busy condition, stations transmit either REJ commands or responses or RR 
commands or response with Nr set to the current value of Vr, depending on whether or’ 
not information fields of correctly received I-frames were discarded. 


Note: DTEs encountering DCE busy conditions, may transmit supervisory command frames 
with ‘'P=1' to solicit the status of the DCE. DTEs that do not implement supervisory 
commands, may use the procedures (Capplicable to LAPB) for DCEs described in "Receiving 
RNR." ; 


2.4.6.8 Waiting for Acknowledgement 


Transmitting stations maintain an internal retransmission count CY) which is set to 
0" upon receipt of a UA or RNR, or upon correct receipt of an I or S-frame with an Nr 
pone. than the last Nr received from the remote station Cactually acknowledging some 
-~frame(s)). . | 
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If Timer Tl Cor Tp for DTEs) expires, stations enter or (re-Jenter the timer recovery 


condition, increment "Y' by one (1) and set an internal variable (X) to the current 
value of Vs.. 


Stations restart timer Tl (Cor Tp for DTEs), set Vs equal to the value of the last Nr. 
received from the remote station and retransmit the corresponding I-frame with 'P=1' 
or transmit an appropriate S-frame with '"P=1"'. 


Timer recovery conditions are cleared upon receipt of a valid S-frame with 'F=1'. 


Upon correct receipt of a supervisory frame with 'F=1' and an Nr within the range from 
the current value of Vs to 'X' included, stations clear the timer recovery condition 
and set Vs equal to the value of Nr received. : 


Upon correct receipt of a supervisory frame with '"F=0' and with an Nr within the range 
from the current value of Vs to 'X' included, stations do not clear the timer recovery 
condition. The received Nr may be used to update Vs. However, stations may retransmit 
the last retransmitted I-frame Ceven if it is acknowledged) with 'P=1' in the event 
that timer Tl Cor Tp for DTEs) expires at a later time. 


When 'Y' is equal to N2 Cor Np for DTEs), stations initiate a resetting procedure as 


described in (text deleted) "Procedure" or "Alternative #17" on page II-21. The values 


of N2 Cand Np for DTEs) are system parameter (see "Maximum Number of Retransmissions, 
N2" on page JI-23). 


Note: Although DCEs implement the internal variable 'X', other mechanisms exist that 
achieve the identical functions. Therefore, internal variable (X) is not necessarily 
implemented in all DTEs. 


(2.4.7 Procedures for Resetting (LAP) 


(Text deleted). 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. 


2.4.8 Re-=23ction Conditions (LAP) 


(Text deleted). 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. 
2.4.9 Procedures for Resetting (LAPB) 


2.4.9.1 Introduction 


The resetting procedures described here are used, only during the information transfer 
phase, to initialize/reinitialize both directions of information transmission. 


2.4.9.2 Procedure 


Stations indicate a resetting by transmitting a SABM command. Upon receipt of a SABM 
command, receiving stations prepared to resume normal link level operation return a UA 
response, at the earliest opportunity, and set Vs and Vr equal to '0'. This also 
clears station busy conditions, if present. DTEs not prepared to resume normal link 
level operations upon receipt of a SABM command transmit a DM response and enter the 
disconnected phase. Prior to initiating this link resetting procedure, stations may 
initiate a disconnect procedure as described in "Link Disconnection" on page II-16. 
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2.4.9.3 Alternative #1 


Under certain rejection conditions listed in "Waiting for Acknowledgement" on page 
II-19 and "Unsolicited DM or FRMR™ on page IJI-22, DCEs may ask the DTE to reset the 
link by transmitting a DM response. 


After transmitting a DM response, DCEs enter the disconnected phase as described in 
item #2 under "Disconnected Phase” on page II-16. 


Upon receipt of a DM response with '"F=0', DTEs prepared to resume normal link layer 
operations may transmit a SABM command with 'P=1' and start timer Tp. 


(Text deleted). 


2.4.9.4 Alternative &2 


Under certain rejection conditions listed in "Erroneous Frame,™ stations may request 
the remote station to reset the link by transmitting a FRMR response. 


After transmitting a FRMR response, transmitting stations enter the frame rejection 
condition. The frame rejection condition is cleared when the station receives a SABM 
or DISC command or a DM response. Other commands received while in the frame rejection 
condition cause receiving stations to retransmit the FRMR response with the same 
information field originally transmitted. 


Upon receipt of a FRMR response, DTES prepared to resume normal link layer operations 
transmit an SABM command with 'P=1"' and start timer Tp. Otherwise, DTEs initiate the 
disconnect procedure described in "Link Disconnection" on page II-16. 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of 
resetting the link layer, notification must be given to a higher layer to protect the 
integrity of the system. 


DCEs may start timer Tl on transmission of the FRMR response. If timer Tl then expires 
prior to the receipt of an SABM or DISC command from the DTE, DCEs may retransmit the 
FRMR response and restart timer Tl. After transmission of the FRMR response N2 times 
DCEs may reset the link as described tn "Procedure" on page II-20. The value of N2 is 
defined in "Maximum Number of Retransmissions, N2" on page II-23. 


2-44.10 Rejection Conditions (LAPB) 


2.%4.10.1 Erroneous Frame 


Stat*ons initiate a resetting procedure as described in "Alternative #2," upon 
reccipt, during the information transfer phase, of a frame with the correct FCS, with 
the address ‘A’ or 'B", and with one of the following conditions: 


® the frame is unknown as a command or as a response; 
° the information field is invalid; or, 
e the frame contains an invalid Nr as defined in "(Text deleted); Frame Reject 


CFRMR) Response" on page II-1ll. 
Coding of the information field of FRMR responses transmitted is given in "(Text 
deleted); Frame Reject CFRMR) Response” on page IJI-l1ll. Bit 13 of this information 
fieid is set to: 


"O’ if the rejected frame was a command; or, 
'1' if the rejected frame was a response. 
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2.%4.10.2 Unsolicited DM or FRMR 


Stations initiate a resetting procedure as described in "Procedure" on page II-20 Cor 
"Alternative #1" for DCEs) upon receipt, during the information transfer phase, of a 
DM response or a FRMR response. — 


2.%4.10.3 Unsolicited UA or ‘F=1" 


Stations may initiate a resetting procedure as described in "Procedure” on page II-20 
(or "Alternative #1" on page II-21 for DCEs) upon receipt, during the information 
transfer phase a UA response or an unsolicited response with 'F=1'. 


2.4.11 Uist of System Parameters 


The system parameters are as follows: 


2.4.11.1 Time-Outs and Time-Limits 


1. DCE Timer, Tl 


The period of timer Tl takes into account whether the timer is started at the 
beginning or at the end of transmission of the frame at the DCE. 


The period of timer Tl, at the expiration of which retransmission of a frame may be 
initiated according to the procedures described in "Procedure for Link Set-Up and 
Disconnection CLAP)" on page II-15 to “Procedures for Information Transfer (Text. 
deleted)" on page II-17, is a system parameter agreed upon for a period of time 
with the network Administration. 


Proper operation of the procedure requires that timer Tl be greater than the 
maximum time between transmission of frames (SABM, DM, DISC, FRMR, I-frames or 
supervisory command frames) and receipt of the corresponding response frame 
returned as an answer to this frame (UA, DM or acknowledging frame). Therefore, 
DTEs should not delay the response or acknowledging frame returned to the above 
frames by more than a value T2 less than Tl, where T2 is a system parameter. 


DCEs will not delay response or acknowledging frames by more than T2. 
2. DTE Time-Out Function, (Ft) 
The duration of the time-out function (CFt) is: 
Ft = CTpeNptTd)eNd 
where: 

Tp is a function of the time allowed by DTEs between the trans- 
mission of command frames and receipt of the corresponding ack- 
nowledging frame. Upon expiration of timer Tp, DTEs retransmit 


the command with 'P=1' and restart timer Tp. 


Np 2'1" is the maximum number of transmissions and retransmis~ 
sions of a frame following the expiration of time Tp. 


Td is typically many time greater than time Tp and is the time 
to be delayed between consecutive repetitions of TpeNp. 


Nd 2"'1' is the maximum number of repetitions of TpeNptTd to be 
performed befcre declaring the link/station to be inoperative. 


Note: Although Td may be defined as zero, experience has shown that when Td='0° 


and Nd='1' are used, links are often declared inoperative prematurely, causing 
unnecessary session outages and user dissatisfaction. 
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It is, therefore, recommended that Tp, Np, Td and Nd have default values that can 
be overridden by customers as experience indicates. 


IBM SNA X.25 DTEs start timer Tp upon completion of transmission of supervisory 
command frames or I-frames with 'P=1' 


3. Time-Limit, T2 


Time-limit T2 is the maximum time allowed between receipt of command frames from 
remote stations and transmission of the appropriate response frames. This value 
is product and configuration specific. T2 must never exceed the time needed to 
transmit-one maximum length frame plus fifty (50) milliseconds. 


2.4.11.2 Maximum Number of Retransmissions, N2 


The value of the maximum number of transmissions and retransmissions of a frame 
following the expiration of timer Tl is a system parameter (N2) agreed upon for a 
period of time with the network Administration. 


2.4.11.3 Maximum Number of Bits in an I-frame, N1 


The maximum permissible number of bits in an I-frame, exclusive of bits inserted for 
transparency, is a system parameter (N1) which depends upon the maximum length of the 
information fields transferred across the DTE/DCE interface Ci.e., 48+(€8 times the 
maximum number of octets allowed in the information field of I-frames)). 


2.4.11.%4 Maximum Number of Outstanding I-frames, K 


The maximum permissible number (CK) of sequentially numbered I-frames that stations may 
have outstanding Ci.e., unacknowledged) at any given time is a system parameter which 
can never exceed seven (7). The value of 'K’* is agreed upon for a period of time with 
the network Administration. It is essential that 'K' be a parameter whose default 
value can be overridden. 


Note: As a result of the further study proposed in "Control (C) Field” on page II-4, 
the permissible maximum number of outstanding I-frames may be increased by the CCITT. 


2.4.11.5 DTE Timer, Ti 


The period of time that the DTE may allow the link to be in the idle channel state 
before considering it to be in the disconnected phase Cout-of-order) state. Ti is 
much larger Tp. 


2.5 MULTI-LINK PROCEDURE 


CCITT Recommendation X.25 (1984) defines formats and procedures for the operation of 
multiple parallel data links between DTEs and DCEs for a given DTE/DCE interface 
appearance. However, this and other additional capabilities defined in CCITT 
Recommendation X.25 (1984) are being evaluated to ascertain their applicability in SNA 
environments and decisions regarding support in IBM SNA X.25 DTEs will be based on 
future technical and business considerations. 


It is, therefore, recommended that LAPB be implemented in such a manner that 


compatibility with the multi-link procedure described in CCITT Recommendation X.25 
€1984) can be maintained. | 
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3.0 DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE 


This and subsequent points relate to the transfer of packets at the DTE/DCE interface 
for both SNA-to-SNA connections and for SNA-to-non SNA connections. The procedures 
apply to packets that are successfully transferred across the DTE/DCE interface. 


Packets transferred across the DTE/DCE interface are contained within the link level 
information field which delimit their length, and only one packet is contained within 
the information field. 


Note: 
1. (Text deleted). 


2. At present, some networks require the data fields of packets to contain an 
integral number of octets. The transmission by the DTE of data fields not 
containing an integral number of octets to networks may cause a loss of data 
integrity. 3 


DTEs wishing universal operation on all networks should transmit packets with data 
fields containing only an integral number of octets. Full data integrity can only be 
assured by exchange of octet-oriented data fields in both directions of transmission. 


IBM SNA X.25 DTEs transmit and receive packets with User Data fields that contain an 
integral number of octets only. 


This point covers a description of the packet level interface for virtual call and 
permanent virtual circuit services (text deleted). As designated in Recommendation 
X.2 C2], virtual call and permanent virtual circuit services are essential (CE) 
services to be provided by all networks. (Text deleted). 


Note: Under study by the CCITT are considerations regarding the amount of duplication 
between datagram, fast select and possible additional virtual call enhancements with 
the objective to minimize the variety of interfaces. 


For SNA-to-SNA connections, virtual circuits (virtual calls or permanent virtual 
circuits) are treated, by SNA DTEs, as real links that can accommodate multiple SNA 
sessions. Permanent virtual circuits are managed like non-switched links while 
virtual calls are managed either like switched links or like non-switched links 
depending upon the implementation at the IBM SNA X.25 DTE. Except for the IBM-5973 
Network Interface Adapter (NIA), IBM SNA X.25 DTEs must use 'Qualified' data packets 
for Logical Link Control (QLLC) or the Enhanced Logical Link Control CELLC) to perform 
adjacent SNA node physical services (see "Logical Link Control (LLC) on SNA-to-SNA 
Connections” on page II-83). Adjacent SNA node physical services, segmentation and 
sequence numbering may be performed with an optional Physical Services Header (PSH) as 
described in Appendix H only for compatibility with the IBM-5973 NIA. 


For SNA-to-non SNA connections, transformation between X.25 and SNA protocols may be 
performed at SNA boundary network nodes. In this environment several implementation 
approaches can be used as described in Appendix I. 


SNA-to-SNA connections and SNA-to-non SNA connections differ only at the packet level. 
Thus, the previous points ("DTE/DCE Interface Characteristics - (physical level)" on 
page II-1 and "Link Access Procedure across the DITE/DCE Interface” on page II-3) apply 
equally to both types of connection. Functions, facilities, formats and procedures in 
"DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE,™ “PROCEDURES FOR VIRTUAL CIRCUIT 
SERVICES" on page II-29, "Procedures for Datagram Service" on page II-45, "PACKET 
FORMATS" on page II-46 and "PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES" on 


page [I-69 that apply only to SNA-to-non SNA connections are enclosed in brackets 


Le. q., [text]). 


(Text deleted). 


Procedures for virtual circuit service Ci.e., virtual call and permanent virtual 
circuit services) are specified in "PROCEDURES FOR VIRTUAL CIRCUIT SERVICES” on page 
II-29. (Text deleted). Packet formats for virtual circuit services are specified in 
"PACKET FORMATS” on page II-46. Procedures and formats for optional user facilities 


| are specified in "PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES" on page I1-69. 
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3.1 LOGICAL CHANNELS 


To enable simultaneous virtual calls and/or permanent virtual circuits (text deleted), 
logical channels are used. Each virtual call and permanent virtual circuit is 
assiqned a Logical Channel Group Number (Cless than or equal to 15) and a Logical 
Channel Number Cless than or equal to 255). For virtual calls, a Logical Channel Group 
Number and a Logical Channel Number are assigned during the call set-up phase. The 
range of logical channels used for virtual calls is agreed upon with the network 
Administration at the time of subscription to the service (see Appendix A). For 
permanent virtual circuits (text deleted), Logical Channel Group Numbers and Logical 
Channel Numbers are assigned in agreement with the Administration at the time of 
subscription to the service (see Appendix A). 


The Logical Channel Group Number and the Logical Channel Number may be managed as a 
single twelve-bit entity (Logical Channel Identifier - LCI). 


3.2 BASIC STRUCTURE OF PACKETS 


Packets transferred across the DTE/DCE interface consist of at least three octets. 
These three octets contatn a general format identifier (GFI), logical channel 
identifier (LCI) and a packet type identifier (PTI). Other fields are appended to 
packets as required (see "PACKET FORMATS" on page II-46). 


Packet types and their use in association with various services are given in Table 
II-5. 
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TABLE II-5 — Packet Types and Their Uses in Various Services 


PACKET TYPE | SERVICE | Mnemonic | 


CALL SET-UP AND CLEARING 
INCOMING CALL CALL REQUEST INC CRQ 
CALL CONNECTED CALL ACCEPTED CCN CAC 
CLEAR INDICATION CLEAR REQUEST CLI CLR 
DCE CLEAR CONFIRMATION DTE CLEAR CONFIRMATION NCC TCC 


DATA CAND INTERRUPT] 
DCE DATA DTE DATA X X NDT TDT 
[DCE INTERRUPT] C[DTE INTERRUPT] NIN TIN 


CDCE INTERRUPT CDTE INTERRUPT 
CGNFIRMATICN] CONFIRMATION] NIC 


FLOW CONTROL AND RESET | 
DCE RR DTE RR X NRR TRR 
DCE RNR DTE RNR NNR TNR 
RESET INDICATION X RSI 
RESET REQUEST RSR 
DCE RESET CONFIRMATION DTE RESET CONFIRMATION NRC TRC: 


RESTART 
RESTART INDICATION RESTART REQUEST IRI IRR 
DCE RESTART CONFIRMATION DTE RESTART CONFIRMATION NSC TSC 


ppracnostrcxe Tf ee 


Virtual Call 
Permanent Virtual Circuit 
Entire DTE/DCE Interface 


pve 
ITF 


¥ 


Not necessarily available on all networks. 
Note: DTE REJ and DATAGRAM packets are not used. 
Text deleted. 


3.3 PROCEDURE FOR RESTART 


The restart procedure is used to initialize or reinitialize the packet level DTE/DCE 
interface. The DTE restart procedure must be executed after link level initialization 
is complete. The DTE/DCE interface becomes operational only upon. successful 
completion of the restart procedure. The restart procedure simultaneously clears all 
virtual calls and resets all permanent virtual circuits (text deleted) at the DIE/DCE 
interface (see "Effects of Clear, Reset and Restart Procedures on the Transfer of 
Packets" on page II-43( text deleted)). 


Figure B-1, in Appendix B, gives the state diagram which defines the logical 
relationships of events related to the restart procedure. 


Table C-2, in Appendix C, specifies actions taken by DCEs upon receipt of packets from 
DTEs for the restart procedure. (Text deleted). 


Table G-2, in Appendix G, specifies the actions taken by DTEs on receipt of packets 
from DCEs for the restart procedure. 


3.3.1 Restart by DTEs 


At any time, after link level initialization is complete, DTEs may initiate a restart 
by transferring a RESTART REQUEST packet across the DTE/DCE interface. The Diagnostic 
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Code field in RESTART REQUEST packets is coded x'00' to indicate initial restart (see 
Appendix F for SNA-to-SNA connections). The interface for each logical channel is 
then in the DTE RESTART REQUEST state (r2). 


DCEs confirm restart by transferring a DCE RESTART CONFIRMATION packet placing logical 
channels used for virtual calls in the READY state (pl), and logical channels used for 
permanent virtual circuits (text deleted) in the FLOW CONTROL READY state (dl). 


Note: States pl and dl are specified in "PROCEDURES FOR VIRTUAL CIRCUIT SERVICES” on 
page [I-29 (text deleted). 


DCE RESTART CONFIRMATION packets can only be interpreted universally as having local 
significance. The time spent in the DTE RESTART REQUEST state (r2) will not exceed 
time-limit T20 (see Appendix D). In this state, DTIEs ignore all packets, except 
RESTART INDICATION and DCE RESTART CONFIRMATION. If the DCE does not confirm this 
restart within 200 seconds, the RESTART REQUEST packet can be retransmitted after the 
200 second timer its reinitialized. If the total time spent in state (r2) exceeds 'n' 
times 200 seconds, where 'n21', notification of failure of the DTE/DCE interface must 
be reported to a higher level by IBM SNA X.25 DTEs using the Diagnostic code x'34'., 
The DTE/DCE interface must be placed in an inoperative state. 


Note: [For SNA-to-non SNA connections the coding of the diagnostic field is a matter 
to be negotiated by the specific non-SNA DTEC(s).] 


3.2 Restart by DCEs 


DCEs may indicate a restart by transferring a RESTART INDICATION packet across the 
DTE/DCE interface. The interface for each logical channel is then in the DCE RESTART 
INDICATION state (r3). In this state of the DTE/DCE interface, DCEs ignore all 
packets except RESTART REQUEST and DTE RESTART CONFIRMATION. IBM SNA X.25 DTEs must 
report the contents of the restart cause and diagnostic fields contained in RESTART 
INDICATION packets to a higher layer. 


DTEs confirm the restart by transmitting a DTE RESTART CONFIRMATION packet across the 
DTE/DCE interface, before timer T10 elapses, placing all logical channels used for 
virtual calls in the READY state (pl) and all logical channels used for permanent 
virtual circuits (text deleted) in the FLOW CONTROL READY state (dl). 


Actions taken by DCEs when DTEs do not confirm the restart within time-out 1T10 are 
given in Appendix D. 


3.3.3 Restart Collision 


Restart collision occurs when a DTE anda DCE simultaneously transfer a RESTART 
REQUEST and a RESTART INDICATION packet. When this occurs, DCEs consider the restart 
to be complete. DCEs do not expect a DTE RESTART CONFIRMATION packet and do not 
transfer a DCE RESTART CONFIRMATION packet. DTEs do not expect a DCE RESTART 
CONFIRMATION packet and do not transfer a DTE RESTART CONFIRMATION packet when a 
restart collision occurs. This places all logical channels used for virtual calls in 
the READY state (pl), and all logical channels used for Permanent virtual circuits 
(text deleted) in the FLOW CONTROL READY state (dl). 


3.4% ERROR HANDLING 


Table C-1, in Appendix C, specifies the reaction of DCEs when special error conditions 
are encountered. Other error conditions are discussed in 8-4. (Text deleted). Table 
G-l, in pooner G, specifies the reaction of DTEs when special error situations are 
encountered. | 
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3.4.1 Diagnostic Packet 


DIAGNOSTIC packets are used by some networks to ‘indicate error conditions in 
circumstances where the usual methods of indication (i.e., reset, clear and restart 
with cause and diagnostic) are not appropriate (see Tables C-1 and D-1). DIAGNOSTIC 
packets from DCEs supply information on error situations that are considered to be 
unrecoverable at the packet level of X.25; the information provided in the diagnostic 
code and explanation fields of DIAGNOSTIC packets must be reported to a higher level 
for error analysis and recovery by IBM SNA X.25 DTEs. No state transition takes place 
on the logical channel to which the DIAGNOSTIC packet is related. 


A DIAGNOSTIC packet is issued only once per particular instance of an error eondi tions 

DTEs do not confirm receipt of DIAGNOSTIC packets. After issuing a DIAGNOSTIC packet, 
DCEs maintain the logical channel(s) to which the DIAGNOSTIC packet is related in the 
same state as that when the DIAGNOSTIC packet was generated. 


3.5 EFFECTS OF THE PHYSICAL LEVEL AND THE LINK LEVEL ON THE PACKET LEVEL 


Changes in operational states at the physical level and the link level of the DTE/DCE 
interface do not implicitly change the state of logical channels at the packet level. 
When such changes occur, they are explicitly indicated at the packet level by the use 
of appropriate clear, reset or restart procedures. 


Failures at the physical and/or link level are conditions in which stations cannot 
transmit and receive any frames because of abnormal conditions caused by, for 
instance, a line fault between the DTE and the DCE. 


When failures at the physical level or the link level are detected, virtual calls are 
cleared and permanent virtual circuits are declared out of order (text deleted) by 
DCEs. Further actions are specified in "Effects of Physical and Link Level Faitlures" 
on page II-44 for virtual circuit services (text deleted). 


When DTEs detect such a failure, or when the link goes into disconnected mode, and link 
level queues are purged by the DTE or the DCE, inoperative notifications must be given 
to higher levels. In this event, inoperative notification are required for the LAPB 
link and for all virtual circuits to cause all using SNA half-sessions to be notified 
of the outage. 


When physical and/or link level failures are recovered, DCEs transmit RESTART 
INDICATION packets with the cause "Network Operational™ to local DTEs. Further 
actions are specified in "Effects of Physical and Link Level Failures" on page II-44 
for virtua: circurt services (text deleted). 


(Text deleted). 

In other out-of-order conditions at the physical and/or link level, including 
transmission of a DISC command by the DTE, the behavior of the DCE is being studied by 
the CCITT. 


IBM SNA X.25 DTEs assume that DCEs clear virtual calls and reset permanent virtual 
circuits when other out of order conditions occur at the physical and/or link level. 


Note: An out-of-order condition on the link level includes receipt of a DISC commands 
by DCEs in the case of a single link procedure. 


(Text deleted). 
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4.0 PROCEDURES FOR VIRTUAL CIRCUIT SERVICES. 


4.1 PROCEDURES FOR VIRTUAL CALL SERVICE 


Figures B-1, B-2 and B-3, in Appendix B, contain state diagrams which define the state 
transitions that occur at the packet level DTE/DCE interface for logical channels used 
for virtual calls. 


Appendix. C gives details of the actions taken by DCEs on receipt of packets in each 
state shown in Appendix B. 


Text deleted. 


Appendix G gives details of the actions taken by DTEs on receipt of packets in each 
state shown in Appendix B. 


The call set-up and clearing procedures, described in the following points, apply 
independently to each logical channel assigned to virtual call service at the DTE/DCE 
interface. 


4.1.1 Ready State 


A logical channel is in the READY state (pl) when no call exists. 


4.1.2 Call Request Packet 


Calling DTEs indicate call requests by transferring CALL REQUEST packets across the 
DTE/DCE interface. The logical channel, selected for the call by the DTE, is then in 
the DTE WAITING state (p2). If the time spent in the DTE WAITING state (p2) exceeds 
200 seconds, the CALL REQUEST packet can be retransmitted after the 200 second timer 
is reinitialized. If the total time spent in state (p2) exceeds 'n' times 200 seconds, 
where 'n21', a CLEAR REQUEST is transmitted and notification of the CALL REQUEST 
failure must be reported to a higher level using the Diagnostic code #49; the logical 
channel is placed in an inoperative state. CALL REQUEST packets include the called 
DTE address. The calling DTE address field may also be used. 


Note: 


1. A DTE address may be a network address, an abbreviated address or any other DTE 
identification agreed upon for a period of time between the DTE and the DCE 


2. CALL REQUEST packets use the logical channel in the READY state (rl) with the 
highest number in the range that has been agreed upon with the network 
Administration (see Appendix A). Thus, the risk of call collision is minimized. 


4.1.3 Incoming Call Packet 


DCEs indicate incoming calls by transferring INCOMING CALL packets across the DTE/DCE 
interface. This places the logical channel, selected by the DCE for the call, tn the 
DCE WAITING state (p3). 


DCEs assign the logical channel in the READY state (rl) with the lowest number (see 
Appendix A) to INCOMING CALL packets. INCOMING CALL packets include the calling DTE 
address. The called DTE address field may also be used. The contents of the called 
DTE address field are ignored by IBM SNA X.25 DTEs. 
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Note: A DTE address may be a DTE network address, an abbreviated address or any other 
DTE . identification agreed upon for a period of time between the DTE and the DCE. 


4.1.4 Call Accepted Packet 


Called DTEs accept calls by transferring CALL ACCEPTED packets, specifying the logical 
channel indicated in INCOMING CALL packets across the DTE/DCE interface, before timer 
T1l1 elapses. This places. the specified logical channel in the DATA TRANSFER state 
(p44). - | ie 


If the called DTE does not accept a call by transmitting a CALL ACCEPTED packet, or 
does not reject it by transmitting a CLEAR REQUEST packet as described in "Clearing by 
DTEs,»"™ within time-out Till (see Appendix D), DCEs consider this to be a procedure 
error on the part of the called DTE and clear the virtual call according to the 
procedure described tn "Clearing by DCEs" on page II-31. 


4.1.5 Call Connected Packet 


Receipt of a CALL CONNECTED packet specifying the logical channel assigned to a 
previous CALL REQUEST packet by a calling DTE indicates that the call has been 
accepted by the called DTE. This places the specified logical channel in the DATA 
TRANSFER state (p4). 


The time spent in the DTE WAITING state (p2) will not exceed time-limit T21 (see 
Appendix D). 


6.1.6 Call Collision 


Call collision occurs when a DTE and DCE simultaneously transfer a CALL REQUEST packet 
and an INCOMING CALL packet specifying the same logical channel. When this occurs, 
DCEs proceed with the call request and cancel the incoming call. DTEs discard the 
INCOMING CALL packet in the event of call collision. 


4.1.7 Clearing by DTEs 


DTEs may indicate call clearing, at any time, by transferring a CLEAR REQUEST packet 
across the DTE/DCE interface (see "Effects of Clear, Reset and Restart Procedures on 
the Transfer of Packets" on page II-43). The specified logical channel is then in the 
DTE CLEAR REQUEST state (p6). DCEs transfer a DCE CLEAR CONFIRMATION packet 
specifying the same logical channel across the DTE/DCE interface when prepared to free 
the logical channel... The logical channel is then in the READY state (pl). 


DCE CLEAR CONFIRMATION packets can only be interpreted universally as having local 
Significance; however, they may have end to end significance in some networks. In any 
event the time spent in the DTE CLEAR REQUEST state (p6) will not exceed time-limit T23 
(see Appendix D). If a DCE CLEAR CONFIRMATION packet is not received within 200 
seconds, the CLEAR REQUEST packet can be retransmitted after the 200 second timer is 
reinitialized. If the total time spent in state (p6) exceeds 'n' times 200 seconds, 
where 'n21', notification of the clear failure must be given to a higher level by IBM 
SNA X.25 DTEs using the Diagnostic code #50; the logical channel is placed in an 
inoperative state. 


Depending upon the state of the logical channel, it is possible for DTEs to receive 
other types of packets between the transfer of a CLEAR REQUEST packet and the receipt 
of the DCE CLEAR CONFIRMATION packet. <Any such packets are discarded by IBM SNA X.25 
DTEs. 


Note: Calling DTEs may abort a call by clearing the cail prior to receipt of a CALL 
CONNECTED or CLEAR INDICATION packet. 
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Called DTEs may refuse an incoming call by clearing it as described in this point 
rather than transmitting a CALL ACCEPTED packet as described in "Call Accepted Packet" 
on page I[I-30. Called DTEs must provide the reason for refusing incoming calls by 
placing an appropriate diagnostic code (see Appendix F) in the Diagnostic Code field 
of CLEAR REQUEST packets. 


6.1.8 Clearing by DCEs 


DCEs indicate call clearing by transferring CLEAR INDICATION packets across the 
DTE/DCE interface (see "Effects of Clear, Reset and Restart Procedures on the Transfer 
of Packets" on page II-43). The specified logical channel is then in the DCE CLEAR 
INDICATION state (p7). DTES respond by transferring a DTE CLEAR CONFIRMATION packet 
across the DTE/DCE interface, before time-out T13 elapses. The specified logical 
channel is then in the READY state (pl). DTEs must report the contents of network 
generated call clearing cause and diagnostic fields to a higher layer. 


Actions taken by DCEs when DTEs do not confirm call clearing within time-out T13 are 
given tn Appendix D. 


46.1.9 Clear Collision 


Clear collision occurs when a DTE anda DCE simultaneously transfer a CLEAR REQUEST 
packet and a CLEAR INDICATION packet specifying the same logical channel. In this 
event, DCEs consider call clearing to be complete. DCEs do not expect a DTE CLEAR 
CONFIRMATION packet and do not transfer a DCE CLEAR CONFIRMATION packet. DTEs do not 
expect a DCE CLEAR CONFIRMATION packet and do not transfer a DTE CLEAR CONFIRMATION 
packet when a clear collision occurs. This places the specified logical channel in 
the READY state (pl). 


4.1.10 Unsuccessful Call 


When a call cannot be established, DCEs transfer a CLEAR INDICATION packet specifying 
the logical channel indicated in the CALL REQUEST packet. IBM SNA X.25 DTEs must 
report the contents of network generated call clearing cause and diagnostic code 
fields to a higher level. 


6.1.11 Call Progress Signals 


DCEs are capable of transferring the clearing call progress signals specified in CCITT 
Recommendation X.96 [4], as clearing cause and/or diagnostic codes, to DTEs. 


Clearing call progress signals are carried in CLEAR INDICATION packets that terminate 
the call to which the packet refers. The method of coding CLEAR INDICATION packets 
containing call progress signals 1s detailed in "Clear Request and Clear Indication 
Packets™ on page II-54. IBM SNA X.25 DTEs must report all clearing call progress 
signals to a higher level. | 


6.1.12 Data Transfer State 


Procedures for the control of packets transferred between DTEs and DCEs in the DATA 
TRANSFER state (p4) are described in "Procedures for Data [and Interrupt] Transfer" on 
page II-32. ; 
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4.2 PROCEDURES FOR PERMANENT VIRTUAL CIRCUIT SERVICE 


Figures B-1 and B-3, in Appendix B, contain state diagrams defining events that occur 
at the packet lavel DTE/DCE interface for logical channels assigned for permanent 
virtual circuits. 


Appendix C gives details of the action taken by DCEs upon receipt of packets in each 
state shown in Appendix B. (Text deleted). 


Appendix G gives details of the action taken by DTEs upon receipt of packets in each 
state shown in Appendix B. 


Call set-up and clearing procedures do not apply to permanent virtual circuits. 
Procedures for the control of packets transferred between DTEs and DCEs while in the 
BATA TRANSFER state (p4) are described in "Procedures for Data [and Interrupt] 
Transfer." 


§.3_ PROCEDURES FOR DATA [CAND INTERRUPT] TRANSFER. 


The data transfer [and interrupt] procedures described ih the following points of 
"Procedures for Data [Land Interrupt] Transfer" apply independently to each logical 
channel assigned for virtual calls and permanent virtual circuits existing at the 
DIE/DCE interface. 


Normal network operation dictates that user data in data [and interrupt] packets are 
all passed transparently, unaltered through the network in the case of packet DTE to 
packet DTE. communications. Order of bits in data packets is preserved. Packet 
sequences: are delivered as complete packet sequences. DTE Diagnostic Codes are 
treated as described in "Clear Request and Clear Indication Packets" on page JI-54;, 
"Reset Request and Reset Indication Packets" on page II-60 and "Restart Request and 
Restart Indication Packets" on page II-62. 


4.3.1 States for Data Transfer 


A virtual call logical channel is in the DATA TRANSFER state (p4) after completion of 


call establishment and prior to a clearing or a restart procedure. A permanent 


virtual circuit logical channel is continually in the DATA TRANSFER state (p4) except 
during the restart procedure. Data, [Linterrupt,] flow control and reset packets may 
be transmitted and received by DTEs in the DATA TRANSFER state (p4) of a logical 
channel at the DTE/DCE interface. In this state, the flow control and reset 
procedures described in "Procedures for Flow Control™ on page II-37 apply to data 
transmission on that logical channel to and from DTEs. 


When a virtual call is cleared, data Cand interrupt] packets may be discarded by the 
network (see "Effects of Clear, Reset and Restart Procedures on the Transfer of 
Packets" on page II-43). In addition, data, [Linterrupt,] flow control and reset 
packets transmitted by DTEs are ignored by DCEs when the logical channel is in the DCE 
CLEAR INDICATION state (p7). 


(Text deleted. ) 


4.3.1.1 SNA-tOo-SNA Connections 


Logical Link Control (LLC, see "Logical Link Control (LLC) on SNA-to-SNA Connections" 
on page II-83) protocols enable IBM SNA X.25 DTE's to cope with the various situations 
that may possibly occur on SNA-to-SNA connections. 


The following actions are taken by IBM SNA X.25 DTEs to protect against possible 
packet losses: 


1. Orderly Clearing 
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Virtual call clearing is normally initiated only upon requests from SNA control 
points which are responsible for making sure that data flows have first been 
quiesced and all sessions using the virtual circuit have been properly 
deactivated. 


2. Accidental Clearing 


When call clearing is initiated by the network, following some network detected 
error conditton, the station is placed in an inoperative state, notification of 
the station outage is given to a higher level causing sessicn outage notifications 
to be propagated according to SNA mechanisms to all half-sessions that were 
sharing the virtual circuit. Inoperative stations are returned to an operational 
state only by stimulus from some higher level SNA protocol. After the station is 
recontacted and sessions are reestablished the SNA session protocols are 
responsible for recovery from any packet loss that may have occurred as a result 
of call clearing. 


4.3.2 User Data Field Length of Data Packets 


The standard maximum User Data field length is '128' octets. 


Other maximum User Data field lengths that may be offered by some network 
Administrations include: 


"16", "32", "64", °256", "512" and '1024' octets. 


An optional maximum User Data field length may be selected for a period of time as the 
default maximum User Data field length common to all virtual calls at the DTE/DCE 
interface (see "Non-Standard Default Packet Sizes" on page II-73). A value other than 
the default may be selected for a period of time for each permanent virtual circuit 
(see "Non-Standard Default Packet Sizes™" on page II-73). Negotiation of maximum User 
Data fields lengths, on a per call basis, may be made with the Fiow Centrol Parameter 
Negotiation facility (see "Flow Control Parameter Negotiation"™ on page II-73). 


IBM SNA X.25 DTE implementations that allow maximum User Data field lengths other than 
"128" octets support the flow control parameter negotiation facility (1i.e., not all 
networks provide the selection of a default maximum length other than '128' octets). 
As a result, a multi-channel interface may be required to simultaneously support 
multiple maximum packet lengths. 


The User Data field of data packets transmitted across the DTE/DCE interface may 
contain any number of octets up to the agreed maximum. 


(Text deleted. ) 


If the User Data field tn a data packet exceeds the locally permitted maximum User Data 
field length, DCEs reset the virtual call or permanent virtual circuit with the 
resetting cause "Local Procedure Error™. Upon receipt of a reset on virtual calls, 
DIEs clear the virtual call and must report the error to a higher level. 


When DTEs receive data packets that exceed the locally permitted User Data field 
length,. they clear the virtual call or reset the permanent virtual circuit with the 
diagnostic code #167, "Packet Too Long” (see Appendix F) and must report the error toa 
higher level. 


4.3.3 Delivery Confirmation (D) Bit 


4.3.3.1 SNA-to-SNA Connections 


The '"D' bit in packets on SNA-to-SNA connections should always be "0". When DTEs 
receive a data packet that contains 'D=1', they clear the virtual call or reset the 
permanent virtual circuit with the Diagnostic Code #174, "Invalid '"D*® Bit Received" 
(see Appendix F) and must report the error to a higher level. 
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Upon receipt of an INCOMING CALL or CALL CONNECTED packet with "D=1", IBM SNA X.25 DTEs 
clear the virtual call with the Diagnostic Code "E9" (Invalid 'D' Bit Request) and 
must report the error to a higher level. 


4.3.3.2 SNA-to-non_SNA Connections 


The setting of the Delivery Confirmation (D) bit is used to indicate whether or not the 
DTE. wishes to receive an end-to-end acknowledgement of delivery, for data it is 
transmitting, by means of the packet receive sequence number (Pr) (see "Procedures for 
Flow Control" on page II-37). 


Note: 


1. Use of the "D’ bit procedure does not obviate the need for a higher level protocol 
agreed upon between participating DITEs which may be used with or without the 'D’ 
bit procedure to recover from user or network generated resets and clearings. 


2. After January 1982, the '"D' bit procedure should be considered an integral part of 
the X.25 DTE/DCE interface. In the interim period, -the 'D'" bit procedure will be 
available on some Public Data Networks and between some pairs of Public Data 
Networks ona bilateral basis. 


During the interim period, Administrations of networks that do not provide the 'D’' bit 
procedure should be.consulted to determine whether the significance of Pr is a local 
updating of the window across the packet level DTE/DCE interface or conveys an 
end-to-end acknowledgement of delivery of data. 


To facilitate the orderly introduction of the 'D’' bit procedures in DTEs and DCEs, the 
following mechanisms are provided. 


Calling DTEs can ascertain during call establishment that the 'D’ bit procedure can be 

used for the call by setting bit 7 in the General Format Identifier of the CALL REQUEST 
packet equal to '1' (Csee "General Format Identifier” on page II-47). Every network or 
part of international network where the "D' bit procedure is available passes this bit 
transparently. Remote DTEs able to handle the '"D’ bit procedure should not regard 
tnis bit being set to "1" in INCOMING CALL packets as invalid. 


Likewise, called DTEs can set bit 7 in the General Format Identifier of the CALL 
ACCEPTED packet equal to '1l'. Every network or part of international network where 
the '"D" bit is available passes this bit transparently. Calling DTEs able to handle 
the '"D’ bit procedure should not regard this bit being set to ‘1’ in CALL CONNECTED 
packets as tnvalid. 


If any network along the path does not support the '"D’ bit procedure, this would be 
indicated by call clearing by the DCE with a cause indicating "Incompatible 
Destination™ and the diagnostic "Invalid General Format Identifier" or by any other 


ea ee an invalid general format identifier at the DTE/DCE interface (see 
able C-1). 


Use by DTEs of the above mechanism in CALL REQUEST and CALL ACCEPTED packets is 
recommended but is not mandatory for using the 'D' bit procedure on virtual calls. 


When 'D'="1" in a data packet ona virtual call or permanent virtual circuit where the 
"D' bit procedure is not available, this will be indicated to both participating DTEs 
by a RESET INDICATION packet with the cause "Incompatible destination" and the 
diagnostic "Invalid general format identifier"; or, by.some other means to indicate an 
invalid general format identifier at the DTE/DCE interface (see Table C-1). 


DTEs may request either local or remote significance and IBM SNA X.25 DTEs” permit 
partner DTEs to operate with end-to-end significance. Thus, bit 7 of the first octet 
(GFI) in CALL REQUEST and CALL ACCEPTED packets may be set to '0’ or "1 according to 
the parameters that, in the SNA "BIND"™ command opening the SNA session corresponding 
to the virtual circuit, indicate whether definite responses are supported for that SNA 
session (see Approach 1 in Appendix I). 


Similarly, the state of bit 7 of the first octet (GFI) in INCOMING CALL packets may be 


used to determine the proper "BIND" protocol. The state of bit 7 of the first octet in 
CALL CONNECTED packets may be compared to the established SNA session and a decision 
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made as to whether compatibility of operation on the virtual circuit and the SNA 
session is guaranteed. 


4.3.% More Data Mark 


Stations wishing to indicate a sequence of more than one packet use a More Data mark 
C'M' bit) as defined below. 


6.3.4.1 SNA-to-SNA Connections 


"M’ bit segmenting is required for IBM SNA X.25 DTEs, but if compatibility with the 
IBM-5973 NIA is required, the PSH segmenting procedure described in Appendix H must be 
implemented as well. 


When PSH segmenting is implemented, the maximum packet size must be the same at the 
local and remote X.25 DTE/DCE interfaces. 


"M=1" as only used in full data packets to indicate that more data follows. 
Recombination with the following data packet may only be performed within the network 
when "M=1'. 


Two categories of data packets, 'A' and 'B’, are defined as shown in Table II-6. Table 
II-6 also illustrates the network's treatment of the '"M’ bit at both ends of virtual 
calls or permanent virtual circuits. 


Upon receipt of a partially filled data packet with "M'="'1", IBM SNA X.25 DTEs on 
SNA-to-SNA connections clear the virtual call or reset the Senmanent vedas circuit 
with the Diagnostic Code 'Al' (Invalid 'M' Bit Packet Sequence). 


4.3.4.2 SNA-to-non_SNA Connections 


The "M' bit can be set equal to '1' in any data packet. '"M=1" ina full data packet or 
in a partially full data packet that also has 'D=1"', indicates that more data follows. 
Recombination with the following data packet may only be performed within the network 
when 'M=1' in a full data packet that also has 'D=0". 


A sequence of data packets with "M=1" in every packet except for the last one will be 
delivered as a sequence of data packets with "M=1' in every packet except for the last 
one when the original packets having ‘'M=1l' are either full Cirrespective of the 
setting of the 'D' bit) or partially full but have 'D=1' 


Two categories of data packets, "A" and 'B', are defined as shown in TABLE II-6. TABLE 


II-6 also illustrates the network's treatment of the 'M' and 'D’' bits at both ends of 
virtual calls or permanent virtual circuits. 
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Table II-6 — Definition of Two Categories of Data Packets and Network 
Treatment of the 'M' bit and the 'D’ bit 


Data Packet © 
Received b 
Destination DTE 


Combining with 
Subsequent packet(s) 
is performed by 
the network 
when possible 


Data packet sent 
by source DTE 


Yes (See Note) 


* — Refers to the delivered data packet whose last bit of user data 
corresponds to the last bit of user data, if any, that was 
present in the data packet sent by the source DTE. 

¥¥ — Valid on SNA-to-non-SNA connections only. 


ae ae 
pe ee ee 
conte ea Be! a a 
a a ee ee 
a ee ee 
pee | oo | a fives Poe 
pa ee 
ae S| 


Note: If the data packet sent by the source DTE is combined with other packets, up to 
and including a category 'B’" packet, the '"M' and 'D’® bit settings in the data packet 
received by the destination DTE will be according to that given in the right hand 
columns for the last data packet sent by the source DTE that was part. of the 
combination. 


4.3.5 Complete Packet Sequence 


A complete packet sequence is composed of ae single category "B’' packet and all | 
contiguous preceding category "A" packets (if any). Category "A" packets have the 
exact maximum User Data field length with '"M=1" and '"D=0"'. All other data packets are 
category ‘'B’ packets. 


Complete sacket sequences, transmitted by source DTEs, are always delivered to the 
destination DTE as single complete packet sequences. 


Thus, when the maximum user data field length at the receiving end is larger than that 
at the transmitting end, packets of complete packet sequences are combined within the 
network. They will be delivered as complete packet sequences where each packet, 
except the last one, has the exact maximum user data field length, '"M=1" and 'D=0". 
The User Data field of the last packet of a sequence may have less than the maximum 

length with the 'M' and '"D' bits set as described in Table II-6. 


When the maximum user data field length is the same at both ends, data fields of data 
packets are delivered to the receiving DTE exactly as received by the network, except 
as follows. If a full packet with "M=1' and '"D=0'" is followed by an empty packet, the 
two packets may be merged so as to become a single category 'B' full packet. If the 
last packet of a complete packet sequence transmitted by the source DTE has a User Data 
field less than the maximum length with '"M=1L' and 'D=0"', the last packet of the 
complete packet sequence is delivered to the destination DTE with '"M=0'. 


When the maximum user data field length at the receiving end is smaller than that at 


the transmitting end, packets will be segmented within the network, and the 'M' and 
"D’ bits set by the network as described to maintain complete packet sequences. 
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4.3.5.1 SNA~tO-SNA Connections Only 


When PSH segmenting is used, the maximum packet length at the local and remote DTE/DCE 
interfaces is the same. Therefore, no ‘M’ bit packet sequences occur at either 
DITE/DCE interface. 


4.3.6 Qualifier Bit 


Complete packet sequences may be transmitted on one of two levels. DTEs wishing to 
transmit data on more than one level use an indicator called the Qualifier ('Q') bit. 


When only one level of data is being transmitted on a logical channel, the Qualifier 
bit is always set to ‘'Q=0"'. When two levels of data are being transmitted, 
transmitting DTEs should set the 'Q’" bit in all data packets of complete packet 
sequences to the same value, either '°'0" or =“‘°'i1'., Complete packet sequences, 
transmitted with the 'Q' bit set to the same value in all packets, are delivered by the 
network as complete packet sequences with the 'Q’ bit in all packets set to the value 
assigned by the transmitting DTE. 


Other sequences of '"Q’ bit settings received cause DTEs to reset the permanent virtual 
circuit or clear the virtual call with the Diagnostic Code #175, “Invalid 'Q'" Bit 
Received™. IBM SNA X.25 DTEs must report the contents of the resetting/clearing cause 
and diagnostic code fields to a higher level. 

Actions taken by networks when the 'Q' bit is not set to the same value in all data 
packets of a complete packet sequence by the transmitting DTE is under consideration 
by the CCITT. 


Packets are numbered consecutively (see "Numbering of Data Packets™ on page II-38) 
regardless of their data level. 


4.3.6.1 SNA~to-SNA Connections 


The "@" bit ts used by IBM SNA X.25 DTEs on SNA-to—-SNA connections to identify data 
packets associated with the QLLC Logical Link Control procedure described in "Logical 
Link Control (LLC) on SNA-to-SNA Connections" on page II-83. 


4.3.6.2 SNA-to-non_SNA Connections 


CCITT Recommendation X.29 provides one example of the procedures to be used when the 
"2" bit ts set to "1'. IBM SNA X.25 DTEs that support CCITT Recommendation X.29 and 
other packet assembly/disassembly CPAD) control procedures implement the 'Q’ bit 
procedure, accordingly. 


4.3.7 Interrupt Procedure 


6.3.7.1 SNA~tO-SNA Connections 


The tnterrupt procedure is not allowed on SNA-to-SNA connections. 
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4.3.7.2 SNA-to-non_SNA Connection | 


Interrupt procedures allow DTEs to transmit data to remote DTEs, without following the 
flow control procedures applying to data packets (see "Procedures for Flow Control™). 
The interrupt procedure applies only during the FLOW CONTROL READY state (dl) within 
the DATA TRANSFER state (p4). 


Interrupt procedures have no effect on the transfer and flow control procedures 
applying to data packets on virtual calls or permanent virtual circuits. : 


Tc transmit an interrupt, DTEs. transfer a DTE INTERRUPT packet across the DTE/DCE 
interface. DTEs do not transmit a second DTE INTERRUPT packet before a DCE INTERRUPT 
CONFIRMATION packet (see Note 2 to Table C-4) has been received. DCEs, after the 
interrupt procedure is completed at the remote end, confirm receipt of interrupts by 
transferring DCE INTERRUPT CONFIRMATION packets. Receipt of DCE INTERRUPT 
CONFIRMATION packets indicate that interrupts have been contirmed by remote DTEs by 
means of DTE INTERRUPT CONFIRMATION packets. | | 


DCEs indicate interrupts from remote DTEs by transferring DCE INTERRUPT packets 
containing the same data field as in the DTE INTERRUPT packet transmitted across the 
DTE/DCE interface by the remote DTE. DCE INTERRUPT packets are delivered at or before 
the point in the stream of data packets at which DTE INTERRUPT packets were generated. 

DTEs confirm receipt of DCE INTERRUPT packets by transferring DTE INTERRUPT 
CONFIRMATION packets across the DTE/DCE interface. 


4.4% PROCEDURES FOR FLOW CONTROL 


"Procedures for Flow Control” on page JI-37 only applies to the DATA TRANSFER state 
Cp4). and specifies the procedures for controlling the flow of data and reset packets 
on logical channels used for virtual calls or permanent virtual circuits. 


6.4.1 Flow Control 


At the DTE/DCE interface of logical channels used for virtual calls or permanent 
virtual circuits, the transmission of data packets is controlled separately for each 
direction of transmission and is based on authorizations from the receiving station. 


On virtual calls or permanent virtual circuits, flow control also allows receiving 
DTEs to limit the rate at which remote DTEs transmit data packets. This is achieved by 
the receiving station controlling the rate at which it accepts packets across the 
DTE/DCE interface, noting that there is a network-dependent limit on the number of 
data packets that can be in the network on a virtual call or permanent virtual circuit. 


4.4.1.1 Numbering of Data Packets 


Data packets. transmitted across the DTE/DCE interface for each direction of 
transmission on a virtual call or permanent virtual circuit are sequentially numbered. 


The sequence numbering scheme of the packets is performed modulo '"8'. The packet 
sequence numbers cycle through the entire range '0" to ‘'7', inclusively. Some 
Administrations provide the Extended Packet Sequence Numbering facility (see 
"Extended Packet Sequence Numbering™ on page II-69) which, if selected, provides a 
sequence numbering scheme for packets being performed modulo '128'. In this case, 
packet sequence numbers cycle through the entire range "0" to '127', inclusively. The 
packet sequence numbering scheme, modulo '8' or '128', is the same for both directions 
of transmission and applies to all logical channels at the DTE/DCE interface. 


Note: IBM SNA X.25. DTEs must implement Modulo ‘'8'" packet sequence numbering. 
Implementation of modulo '128' packet sequence numbering is optional. 


eee data packets contain this sequence number called the packet send sequence number, 
Ss. 
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The first data pactret transmitted across the DTE/DCE interface for a given direction 
of data transmissior, wren the logical channel has just entered the FLOW CONTROL READY 
state (dl), has "Ps=C"'. 


4.4.1.2 Window Description 


At the DTE/DCE interface of each logical channel used for virtual calls or permanent 
virtual circuits, and for each direction of data transmission, a window is defined as 
the ordered set of ‘'W" consecutive packet send sequence numbers of data packets 
authorized to cross the interface. 


The lowest sequence number in the window is referred to as the lower window edge. When 
a virtual call or permanent virtual circuit at the DTE/DCE interface has just entered 
the FLOW CONTROL READY state (dil), the window related to each direction of data 
transmission has a lower window edge equal to '0’. 


The Ps of the first data packet not authorized to cross the DTE/DCE interface is the 
value of the lower window edge plus 'W’' modulo '8' Cor '128' when extended). 


The standard window size, 'W', is two (2) for each direction of data transmission at 
the DTE/DCE interface. Other window sizes may be offered by some network 
Administrations. An optional window size may be selected for a period of time as the 
default window size common to all virtual calls at the DTE/DCE interface (see 
"Non-Standard Default Window Sizes" on page II-69). A value other than the standard 
default may be selected for a period of time for each permanent virtual circuit (see 
"Non-Standard Default Window Sizes" on page II-69. Negotiation of window sizes, ona 
per call basis, may be made with the Flow Control Parameter Negotiation facility (see 
"Flow Control Parameter Negotiation” on page II-73). 


IBM SNA X.25 DTEs must implement 'W=2' and also allow values other than 'W=2', namely, 
"W’ < 'modulus’ to be set as determined at subscription time. When the access link to 
the network exhibits long delay characteristics and the packets used are short, IBM 
SNA X.25 DTEsS may implement the optional Flow Control Parameter. Negotiation facility 
as not all networks permit selection of default values other than 'W=2". 


4.4.1.3 Flow Control Principles 


When the Ps of the next packet to be transmitted is within the window, transmitting 
stations are authorized to transmit that data packet to the receiving station. When 
the Ps of the next data packet to be transmitted is outside of the window, transmitting 
stations do not transmit data packets. (Text deleted). 


When the Ps of the data packet received is the next in-sequence (text deleted) 
receiving stations may accept the data packet. A received data packet containing a Ps 
that is out of sequence (i.e., there is a duplicate or a gap tn the Ps numbering), 
outside the window or not equal to ‘'0' for the first data packet received after 
entering the FLOW CONTROL READY state (dl) is considered by DCEs to be a local 
procedure error. In this event DCEs reset the virtual call or permanent virtual 
circuit (see "Procedure for Reset” on page II-42). er consider the receipt of a data 
packet containing a Ps that is out of sequence (i.e., there is a duplicate or a gap in 
the Ps numbering), (text deleted) or not equal to '0O' for the first data packet 
received after entering the FLOW CONTROL READY state (dl) to be a hard DCE failure and 
either clear the virtual call or reset the permanent virtual circuit, or restart the 
DTE/DCE interface. The contents of clearing/resetting Cause and Diagnostic Code 
fields must be reported to a higher level. 


Some networks do not invoke the error procedure on receipt of data packets containing 
a Ps that is out of sequence but is within the window. These networks may pass on such 
packets to remote DTEs to make it possible for local DTEs to retransmit packets on 
virtual calls or permanent virtual circuits (within the national network). 


Because packets should never get out of order on SNA-to-SNA connections Cpacket level 
retransmission does not occur), an out-of—-sequence Ps should be treated as an error. 
DTEs clear the virtual call or reset the permanent virtual circuit Con SNA-to-SNA 
connections with the diagnostic code #171', "Invalid PS", see Appendix F) and must 
report the error to a higher level. 


PROCEDURES FOR VIRTUAL CIRCUIT SERVICES | LI=s9 


SNA/X.25 DTE/DCE Interface 


A number mudulo '8' Cor "128" when extended) referred to as a packet receive sequence 
number (Pr), conveys information from the receiver across the DTE/DCE interface for 
the transmission of data packets. Pr's become the lower window edge when transmitted 
across the DTE/DCE interface. In this way, additional data packets are authorized to 
cross the DTE/DCE interface by the receiving station. 


Pr's are conveyed in data, receive ready (RR) and receive not ready (RNR) packets. 


The value of a Pr received must be within the range from the last Pr received up to and 
including the Ps of the next data packet to be transmitted. Otherwise, DCEs consider 
the receipt of this Pr to be a procedure error and reset the virtual call or permanent 
virtual circuit. DTEs consider the receipt of a Pr value that is not within the range 
from the last Pr received up to and including the Ps of the next data packet to be 
transmitted as a DCE hard failure and either reset the permanent virtual circuit or 
clear the virtual call, or restart the DTE/DCE interface. Such failures must be 
reported to a higher level. On SNA-to-SNA connections the Diagnostic Code #172', 
"Invalid Pr", (see Appendix F) is used. 


Pr‘s are less than or equal to the sequence number of the next expected data packet and 
imply that the transmitting station has accepted at least all data packets numbered up 
to and including ‘'Pr-1'. 


4.49:1.4 Delivery Confirmation 


When ‘'D=0" in a data packet having 'Ps=p', significance of the returned Pr 
corresponding to that data packet (Ci.e., "Pr2ptl') is a local updating of the window 
across the packet level DTE/DCE interface so that the achievable throughput is not 
constrained by the DTE-to-DTE round trip delay across the network(s). 


1. SNA-to-SNA Connections 


"D=1*" is not allowed on SNA~-to-SNA connections. If a packet with 'D=l’ is 
received on an SNA-to-SNA connection, IBM SNA X.25 DTEs clear the virtual call or 
reset the permanent virtual circuit with the Diagnostic Code #173, "Invalid 'D' 
Bit Received in Data Packet” (see Appendix F). 


If an INCOMING CALL or CALL CONNECTED packet is received with bit 7="1", IBM SNA 
X.25 DTEs clear the call with the Diagnostic Code #233, "Invalid 'D' Bit Request" 
(see Appendix F). In all cases, the error condition and Cause and Diagnostic 
codes must be reported to a higher level. 


2. SNA-to-non_SNA Connections 


When *D=1" in a data packet having 'Ps=p', the significance of the returned Pr 
corresponding to that data packet (i.e., "Pr2ptl') is an indication that a Pr has 
been received from the remote DTE for all data bits in the data packet which 
originally had 'D=1'. 


Note: 


1. DTEs, upon receipt of a data packet with ‘'D=1"', transmit the corresponding Pr as 
soon as receipt of the packet at its destination within the SNA network has been 
acknowledged by the appropriate response. Data, RR or RNR packet may be used to 
convey the Pr (see note to "DTE and DCE Receive Not Ready (RNR) Packets." 
Likewise, DCEs are required to send Pr to the DIE as soon as possible after the Pr 
is received from the remote DTE. DTEs should not defer updating the window for 
foe packets with ‘'D=0' while waiting for acknowledgement of a packet with 
"D=1', 


2. In the case where a Pr for a data packet with 'D=1' is outstanding, local updating 
of the window is deferred for subsequent data packets with 'D=0". Some networks 
may also defer updating the window for previous data packets (within the window) 
with "D=0" until the oPresroneune) Pr for the packet with the outstanding 'D=l1' is 
transmitted to the DTE. 


3. Pr values correspondins to the data contained in data packets with the "D=1' need 
not be the same at the DTE/DCE interfaces at each end of a virtual call or 
permanent virtual circuit. 
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4. If the virtual call has not been established indicating support of the 'D’' bit 
procedure, IBM SNA X.25 DTEs do not send data packets with 'D=1'. If they receive 
a packet with '"D=1" from a non-SNA DTE they accept the packet by returning the 
corresponding Pr as soon as possible, without waiting for any SNA acknowledgement. 


6.4.1.5 DTE and DCE Receive Ready (RR) Packets 


RR packets are used by transmitting stations to indicate that they are ready to 
receive the 'W' data packets within the window starting with Pr, where Pr is indicated 
in the RR packet. 


4.4.1.6 DTE and DCE Receive Not Ready (RNR) Packets 


RNR packets are used by transmitting stations to indicate a temporary inability to 
accept additional data packets for a given virtual call or permanent virtual circuit. 
Stations receiving an RNR packet stop transmitting data packets on the indicated 
logical channel, but the Window is updated by the Pr value of the RNR packet. The 
receive not ready situation indicated by the transmission of an RNR packet is cleared 
by the transmission in the same direction of an RR packet or by initiation of a reset 
procedure. 


The transmission of an RR packet after an RNR packet at the packet level is not to be 
taken as a demand for retransmission of packets which have already been transmitted. 


Note: RNR packets may be used to convey the Pr value corresponding to the data packet 
which had 'D=1' across the DTE/DCE interface when additional data packets cannot be 
accepted on SNA-to-non_SNA connections. 


6.4.2 Throughput Characteristics and Classes 


The attainable throughput on virtual calls and permanent virtual circuits carried at 
the DTE/DCE interface may vary due to the statistical sharing of transmission and 
switch resources and is constrained by: 


e the access line characteristics, local window size and traffic characteristics of 
other logical channels at the local DTE/DCE interface; 


@ the access line characteristics, local window size and traffic characteristics of 
other logical channels at the remote DTE/DCE interface; and, 


° the throughput achievable on the virtual call or permanent virtual circuit through 
the network(s) independent of interface characteristics including number of 
active logical channels. This throughput may be dependent on network service 
characteristics such as window rotation mechanisms and/or optional user 
facilities requested on national/international calls. 


The attainable throughput will also be affected by: 
@. the receiving DTE flow controlling the DCE; 


e the transmitting DTE not sending data packets.which have the maximum data field 
length; 


® the local DTE/DCE window and/or packet sizes; and, 

° [the use of the 'D' bit.] 

A throughput class for one direction of transmission is an inherent characteristic of 
the virtual call or permanent virtual circuit related to the amount of resources 
allecated to this virtual call or permanent virtual circuit. This characteristic is 


meaningful when 'D=0' in data packets. It is a measure of the throughput that is not 
normally exceeded on the virtual call or permanent virtual circuit. However, due to 
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the statistical sharing of transmission and switching resources, it is not guaranteed 
that the throughput class can be reached 100% (of the time. 


Heoendine on the network and the spp eenbie Eondy eens at the considered moment, the 
effective throughput may exceed the throughput class. 


Text deleted. | | 
The throughput class may only be reached if the following conditions are met: 


1. the access data links at both ends of a virtual call or permanent virtual EEneuis 
are engineered for the throughput class; 


2. the receiving DTE is not flow controlling the DCE such that the throughput class 
is not reachable; 


3. the transmitting DTE is sending data packets which have the maximum data field 
length; and, 


4. all data packets transmitted on the virtual call or permanent virtual circuit have 
*D= O° 


Throughput class 15 expressed in bits per second. At a DTE/DCE interface, the maximum 
user data field length is specified for a virtual call or permanent virtual circuit, 
and thus the throughput class can be interpreted by DTEs as the number of full data 
packets/serond that the DTE does not have a need to exceed. 


In the absence of the Default Throughput Class Assignment facility (see "Default 
Throughput Classes Assignment" on page II-69), the default throughput classes for both 
directions of transmission correspond to the user class of service of the DTE (see 
"Coding of Throughput Class Negotiation Facility” on page II-81) but do not exceed the 
maximum throughput class supported by the network. Negotiation of throughput classes 
on a per call basis may be made with the Throughput Class Negotiation facility (see 
"Throughput Class Negotiation” on page II-74). 


Note: The summation of throughput classes of all virtual calls and permanent virtual 
circuits (text deleted) supported at a DTE/DCE interface may be greater than the data 
transmission rate of the access line. 


4.4.3 Procedure for Reset 


The reset procedure is used to reinitialize virtual calls or permanent virtual 
circuits and in so doing removes in each direction of transmission all data [Cand 
interrupt] packets which may be in the network (see "Effects of Clear, Reset and 
Restart Procedures on the Transfer of Packets" on page II-43). When a virtual call or 
permanent virtual circuit at the DTE/DCE interface has just been reset, the window 
related to each direction of data transmission has a lower window edge equal to ‘0’, 
and the numbering of subsequent data packets to cross the DTE/DCE interface for each 
direction of data transmission starts from '0'. 


The reset procedure can only apply in the DATA TRANSFER state (p4%) of the DTE/DCE 
interface. In any other state of the DTE/DCE interface, the reset procedure is 
abandoned. For example, when a clearing or restarting procedure is initiated, RESET 
REQUEST and RESET INDICATION packets can be left unconfirmed. 


For flow control, there are three states di, d2, and d3 within the DATA TRANSFER state 
(p4). They are FLOW CONTROL READY (C(d1), DTE RESET REQUEST (€d2), and DCE RESET 
INDICATION (€d3) as shown in the state diagram in Figure B-3 of Appendix B. When 
entering state p4, the logical channel is placed in state dl. Table C-4% specifies 
actions taken by DCEs upon receipt of packets from DTEs. Table G-4, in Appendix G, 
specifies actions taken by DTEs upon receipt of packets from DCEs. 


4.4.3.1 Reset Request Packet 


DTEs indicate requests for resetting of permanent virtual circuits by transmitting a 
RESET REQUEST packet, specifying the logical channel, across the DTE/DCE interface. — 
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This places the specified logical channel in the DTE RESET REQUEST state (d2). DTEs 
discard data, Cinterrupt,] RR, and RNR packets received on logical channels in the DTE 
RESET REQUEST state. Packets of incomplete packet sequences received in this state, 
are also discarded. 


A diagnostic code as defined in Appendix F must be included. Error conditions that 
cause a reset must be reported, with associated diagnostic codes, to a higher level. 
If the time spent in state (d2) exceeds 200 seconds, the RESET REQUEST packet can be 
restransmitted after the 200 second timer is reinitialized. If the total time spent 
in state (d2) exceeds ‘n' times 200 seconds, where ‘'n21l", notification of the RESET 
REQUEST failure must be reported to a higher level using the diagnostic code #51; the 
logical channel is placed in an inoperative state. 


4.4.3.2 Reset Indication Packet 


DCEs indicate a reset by transmitting a RESET INDICATION packet, specifying the 
logical channel and the reason for the resetting, across the DITE/DCE interface. This 
places the specified logical channel in the DCE RESET INDICATION state (€d3). DCEs 
ignore data, Cinterrupt,] DTE RNR and DTE RR packets received on logical channels in 
the DCE RESET INDICATION state. DTEs discard untransmitted packets of send packet 
sequences and must notify a higher layer of the inoperative condition, reporting the 
contents of the resetting cause and diagnostic fields. : 


IBM SNA X.25 DTEs that receive RESET INDICATION packets on logical channels assigned 
for virtual calls clear the virtual call with the diagnostic code #234, "Reset 
Indication on Virtual Call”. 


RESET INDICATION packets are used aS ae ~normal sequence for packet level 
initialization, e.g.: 


® A RESET INDICATION packet with Cause "Out-of-Order (€#1)" is returned by the 
X.25-based network to indicate that the remote DTE/DCE interface has not, as yet, 
been initialized. 


® A RESET INDICATION packet with Cause "DTE Originated '0'" and Diagnostic Code "PU 
Not Available #226" is returned by an SNA NIA to indicate that the SNA SDLC link 
has not, as yet, been initialized. 


e RESET INDICATION packets are propagated by X.25-based networks for each permanent 
virtual circuit as a result of a restarting procedure at the remote DTE/DCE 
interface. Such RESET_INDICATION packets may contain either: 


= the network generated Cause '9" (Remote DTE Operational) with an appropriate 
Diagnostic code; or, 


= the DTE Originated Cause '0° with the Diagnostic code passed through from the 
associated RESTART_REQUEST packet. 


4.4.3.3 Reset Collision 


Reset collision occurs when a DTE and a DCE simultaneously transmit a RESET REQUEST 
packet and a RESET INDICATION packet specifying the same logical channel. In this 
event DCEs consider the reset to be complete. DCEs do not expect a DTE RESET 
CONFIRMATION packet and do not transfer a DCE RESET CONFIRMATION packet. DTEs do not 
expect a DCE RESET CONFIRMATION packet and do not transfer a DTE RESET CONFIRMATION 
packet when a reset collision occurs. This places the specified logical channel in 
the FLOW CONTROL READY state (dl). 


4.4.3.4 Reset Confirmation Packets 


When a logical channel is in the DTE RESET REQUEST state (d2), DCEs confirm the reset 
by transmitting a DCE RESET CONFIRMATION packet across the DTE/DCE interface. This 
places the specified logical channel in the FLOW CONTROL READY state (dl). 
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DCE RESET CONFIRMATION packets can only be interpreted universally as having local 
significance, however, within some Administration's networks, reset confirmation may 
have end-to-end significance. In any event the time spent in the DTE RESET REQUEST 
state (d2) will not exceed time-limit T22 (see Appendix D). 


When logical channels are in the DCE RESET INDICATION state (d3), DTEs confirm the. 
reset by transmitting a DTE RESET CONFIRMATION packet before time T12 elapses. This. 
places the specified logical channel in the FLOW CONTROL READY state (dil). Actions 
patie GA a when DTEs do not confirm the reset within time-out T12 are given in 
Appendix D. 


4.5 EFFECTS OF CLEAR, RESET AND RESTART PROCEDURES ON THE TRANSFER OF PACKETS 


All data [Land interrupt] packets generated by a DTE (or the network) before initiation 
of a clear, reset or restart procedure by a station at the local interface are either 
delivered to the remote DTE before the DCE transmits the corresponding indication on 
the remote interface, or discarded by the network. 


Data Cor interrupt] packets generated by a DTE Cor the network) after the completion 
of a reset (or for permanent virtual circuits also a restart) procedure at the local 
interface are not delivered to the remote DTE before completion of the corresponding 
reset procedure at the remote interface. 


When a DTE initiates a clear, reset or restart procedure on its local interface, all 
data and Cinterrupt] packets which were generated by the remote DTE (or the network) 
before the corresponding indication is transmitted to the remote DTE are either 
delivered to the initiating DTE before DCE confirmation of the initial clear, reset or 
restart request, or discarded by the network. 


Note: The maximum number of packets that may be discarded is a function of network 
end-to-end delay and throughput characteristics and, in general, has no relation to 
the local window size. (CText deleted. ) 


(Text deleted.) 


4.5.1 SNA-to-non SNA Connections 


(For virtual calls on which all data packets are transferred with the "D=1', the 
maximum number of packets that may be discarded in one direction of transmission 15s 
never larger than the window size for the direction of transmission]. 


4.6 EFFECTS OF PHYSICAL AND LINK LEVEL FAILURES 

When a failure at the pnysical and/or link level is detected, DCEs transmit to the 
remote end: 

1. a reset with the cause "Out of Order” for each permanent virtual circuit; and, 

2. aclear with the cause "Out of Order" for each existing virtual call. 

DCEs clear incoming virtual calls received until the failure is recovered. 

When physical and link level failures are recovered, a restart procedure is executed 
(see "Effects of the Physical Level and the Link Level on the Packet Level™ on page 
II-28) and a reset with the cause "Remote DTE Operational” is transmitted to the 


remote end of.each permanent virtual circuit. DTEs must report "Out of Order™ cause 
and diagnostic codes to a higher level. 
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5.@ PROCEDURES FOR DATAGRAM SERVICE 


Datagram services are not used by IBM SNA X.25 DTEs. In the event that a DATAGRAM or 
DATAGRAM SERVICE SIGNAL packet is received, IBM SNA X.25 DTEs clear the virtual call 
or reset the permanent virtual circuit with the Diagnostic Code #170 "Not Supported’. 


(Text deleted). 
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6.0 PACKET FORMATS 


6.1 GENERAL 


The possible extension of X.25 packet formats by the addition of new fields is being 
considered by the CCITT. 


Note: <Any such field: 


1. would only be provided as additions following all previously defined fields, and 
not as insertions between any previously defined fields; | 


2. would be transmitted to a DTE only when either the DCE has been informed that the 
DTE.is able to interpret this field and act upon it, or when the DTE can ignore the 
field without adversely affecting the operation of the DCE; and, 


3. would not contain any information pertaining to a user facility to which the DTE 
has not subscribed. 


Bits of an octet are numbered 8 to 1 where bit 1 is the low order bit and is 
transmitted first. Octets of a packet are consecutively numbered starting from ‘1’ 
and are transmitted in this’ order. Octets of sub-fields within a packet are 
consecutively numbered starting from '0°'. 
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For example a packet: 


Bits 
8 7 6 5 4 3 2 1 
Octet 
1 General format identifier (GFI) Logical channel group number 
0 0 0 1 0 0 1 0 
2 Logical channel number | 
0 0 0 1) 0 0 0 1 
3 Packet type identifier 
0 0 0 0 1 0 1 1 
4 Calling DTE address length Called DTE address length 
0 1 0 0 0 1 0 1 
5 Called 
DTE 
6 Address 
7 Calling 
DTE 
8 Address 
9 
Facility Length 
10 0 0 0 0 0 0 
Call Protocol Identifier 
User 1 1 0 0 0 1 1 
Data |}Fom- rm rm rr er rm er mr rrr rm rrr rr err sss eee 
Field Up to 15 Octets 


would appear on the transmission link as a string of: 


° binary bits in the order: 
"xxx. ..xxx1100001100000000..... 0000000100010010'>>; 

e hexadecimal digits in the order: 
"XK y eee re KeK2Cr3,0,0..... »0,1,1,2'>>3 or, 

e octets containing hexadecimal values in the order: 
"KX,..-2XMXrC35,00,..... 201,12'>>, 

where the first bit(€s) transmitted are immediately to the left of ">>. 


Figure 1. Octet Numbering: Call Set-up/Clearing Packet 


6.1.1 General Format Identifier 


The General Format Identifier (GFI) field is a four bit binary coded field that 
indicates the general format of the rest of the packet header. The General Format 
Identifier field occupies bit positions 8, 7, 6 and 5 of octet 1, and bit 5 is the low 
order bit (see Table JI-7). 
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Table II-7 — General Format Identifier 


General format identifier 


Sequence Numbering Scheme 0X01 
modulo 8 


packets Sequence Numbering Scheme 0X10 


modulo 128 


XX Ol 
Xx X10 
Sequence numbering Scheme 100901 
Datagram service signal modulo 8 
packets 


Sequence Numbering Scheme 1060190 
modulo 128 
General Format Identifier extension px x11 | 


* Undefined 


Call set-up 


Clearing, datagram, flow 
control, interrupt, reset, 
restart and diagnostic 
packets 


Sequence Numbering Scheme 
modulo 8 


Sequence Numbering Scheme 
modulo 128 


Sequence Numbering Scheme 
modulo 8 
Data packets : 
Sequence Numbering Scheme 
modulo 128 


Note: A bit which is indicated as "X" may be set to either '0" or ‘1’ as 
indicated in the text. 


Bit 8 of the General Format Identifier is the Qualifier "Q' bit in data packets. (Text 
deleted). 


Bit 7 of the General Format Identifier is used for the delivery confirmation procedure 
in data and call set-up packets and is set to '0' in all other packets. It must be ‘0° 
in all packets on SNA-to-SNA connections. 


Bits 6 and 5 are encoded for four possible indications. Two of the codes are used to 
distinguish packets using modulo '8' packet sequence numbering from packets using 
modulo ‘'128' packet sequence numbering. The third code is used to indicate an 
extension to an expanded format for a family of General Format Identifier codes which 
are being considered by the CCITT. The fourth code is unassigned. 


Note: 


1. In the absence of the extended packet sequence numbering facility (see "Extended 


Packet Sequence Numbering" on page II-69), the sequence numbering scheme is 
performed modulo 8 


2. It is envisaged that other general format identifier codes could identify 
alternative packet formats. 


6.1.2 togical Channel Group Number 


The Logical Channel Group Number appears in every packet except restart packets and 
diagnostic packets in bit positions 4, 3, 2 and 1 of octet 1. For each logical. 
channel, this number has local significance at the DTE/DCE interface. 
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This field is binary coded and bit 1 is the low order bit of the Logical Channel Group 
Number. In restart and diagnostic packets, this field is coded x'90'. 


6.1.3 Logical Channel Number 


The Logical Channel Number appears in every packet except restart packets and 
diagnostic packets in all bit positions of octet 2. For each logical channel, this 
number has local significance at the DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the Logical Channel 
Number. In restart and diagnostic packets, this field is coded x'00". 


6.1.4 Packet Type Identifier 


Each packet is identified in octet 3 as shown in Table II-8. 


Table II-8 — Packet Type Identifier 


PACKET TYPE 


From DCE to DTE From DTE to DCE 


CALL SET-UP AND CLEARING 
INCOMING CALL — INC CALL REQUEST — CRQ 
CALL CONNECTED — CCN CALL ACCEPTED —CAC 
CLEAR INDICATION — CLI CLEAR REQUEST — CLR 
DCE CLEAR DTE CLEAR 
CONFIRMATION — NCC CONFIRMATION — TCC 


DATA AND CINTERRUPT] 
DCE DATA — NDT DTE DATA — TDT 
DCE CINTERRUPT] — NIN DTE LINTERRUPT] — TIN 
DCE CINTERRUPT] DTE CINTERRUPT] 
CONFIRMATION — NIC CONFIRMATION — TIC 


DATAGRAM® 
DCE DATAGRAM DTE DATAGRAM 
DATAGRAM SERVICE SIGNAL 


FLOW CONTROL AND RESET 

DCE RR (MOD 8) — NRR DTE RR CMOD 8) — TRR 
DCE RR CMOD 128) " DTE RR (MOD 128) ub 
DCE RNR CMOD 8) — NNR DTE RNR CMOD 8) — TNR 
DCE RNR (MOD 128) = DTE RNR (MOD 128) U 

DTE REJ (MOD 8) 

DTE REJ (MOD 128)* 
RESET INDICATION — RSI RESET REQUEST — RSR 
DCE RESET DTE RESET | 
CONFIRMATION — NRC CONFIRMATION — TRC 


RESTART 
RESTART INDICATION — IRI RESTART REQUEST — IRR 
DCE RESTART DTE RESTART 
CONFIRMATION — NSC CONFIRMATION — TSC 


DIAGNOSTIC 


~ mMORDODCCa 
—~ MRRP ODOS 
~~ OODOFKOAQ 
—- MPODeoo0e 
To ee 


DIAGNOSTICX® — DGN 


* = Not necessarily available on every network. 


Notes A bit which is indicated as "X" may be set to either "0" or '1' as 
indicated in the text. 
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6.2 CALL SET-UP AND CLEARING PACKETS 


6.2.1 Call Request and Incoming Call Packets 


Figure 2 illustrates the format of CALL REQUEST and INCOMING CALL packets. 


| Bits 
8 7 6 5 G 3 2 1 
Octet : 
1 General Format Identifier (GFI) Logical Channel Group Number 
2 Logical Channel Number 
3 Packet Type Identifier 
0 0 1 


4 Calling DTE Address Length 


‘ Facility Length 


Facilities 


n Call User Data (see Notes 3 and 4) 


Figure 2. CALL REQUEST and INCOMING CALL: Packet Format 
Notes to Figure 2: 
1. GFI - Coded 0X01 (modulo 8) or 0X10 (modulo 128). 
Where: "X = 0° on SNA-to-SNA Connections. 
"*X = 0 or 1' on SNA-to-non SNA Connections. 


2. The figure is drawn assuming a single address, consisting of an odd number of 
octets, 15 present. 


3. The first octet of the Call User Data field is required and bits 8» 7 and 2 have 
particular significance (see Protocol Identifier (PI)). 


4. Maximum length of the call user data field is 16 Octets. 
5. The Calling DTE Address in CALL REQUEST packets is optional. 
6. Facilities in CALL REQUEST and INCOMING CALL packets are optional. 


6.2.1.1 General Format Identifier 


On SNA-ta-non SNA connections, bit 7 of octet 1 is set to '0* unless the '"D' bit 
mechanism defined in "Delivery Confirmation (D) Bit™ on page II-33 is used. CALL 
REQUEST and INCOMING CALL packets must have bit 7 of octet 1 set to "0" on SNA-to-SNA 
connections. 


6.2.1.2 Address Lensths Field 


Octet & censists of field length indicators for the called and calling DTE addresses. 
Bits 4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 
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8» 7, 6 and 5 indicate the length of the calling DTE address in semi-octets. Each 
par eet length indicator is binary coded and bit 1 or bit 5 is the low order bit of the 
indicator. 


6.2.1.3 Address Field 


Octet 5 and the following octets consist of the called DTE address, when present, then 
the calling DTE address, when present. 


Each digit of an address is coded ina semi-octet in binary coded decimal with bit 5 or 
bit 1 being the low-order bit of the digit. 


Starting from the high order digit, the address is coded in octet 5 and consecutive 
octets ela two digits per octet. In each octet, the higher order digit is coded in 
bits 8», 7, 6 and 5. 


The Address field is rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field when necessary. 


(Text deleted. ) 


6.2.1.4 Facility Length Field 


Bits 6, 5, 4, 3, 2 and 1 of the octet following the Address field indicate the length 
of the Facility field in octets. The facility length indicator is binary coded and bit 
1 is the low order bit of the indicator. 


Bits 8 and 7 of this octet are unassigned and set to "0's. 


6.2.1.5 Facility Field 


The Facility field is present only when the DTE is using an optional user facility 
requiring some indication in CALL REQUEST and INCOMING CALL packets. 


The coding of the Facility field is defined in "PROCEDURES AND FORMATS FOR OPTIONAL 
USER FACILITIES” on page II-69. 


The Facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities that are offered by the network. However, this 
maximum does not exceed 63 octets. 


6.2.1.6 Call User Data Field 


Octets following the Facility field are the Call User Data field, which must be an 
integral number of octets and has a maximum length of 16 octets. 


Protocol Identifier (PI) 


The first octet of the Call User Data field is the Protocol Identifier which is 
mandatory in SNA environments. 


(Text deleted). 


The use and format of the Call User Data field is determined by the setting of bits 8 
and 7 of the first octet of this field (Protocol Identifier). If bits 8 and 7 of the 
first octet of the Call User Data field are: 


e *O60" a portion of the Call User Data field is used for protocol identification in 


accordance with CCITT Recommendation X.29. This setting is not considered for IBM 
SNA X.25 DTEs tn this version of the specification. 
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® "O01' a portion of the Call User Data field may be used for protocol identification 
in accordance with the specifications of network Administrations. This setting is 
not considered for IBM SNA X.25 DTEs in this version of the specification. 

e "10" a portion of the Call User Data field may be used for protocol identification 
in accordance with specifications of international user bodies. This setting is 
not considered for IBM SNA X.25 DTEs in this version of the specification. 

e "11" the Call User Data belongs to a higher level, 


Users are cautioned that if bits 8 and 7 of the first octet of the Call User Data field 
are set to any value other than '11', a protocol may be identified that is implemented 
within some public data networks. 


Receipt of an incorrect setting of bits 8 or 7 Cother than '11'), by IBM SNA X.25 DTEs 
results in call clearing with the diagnostic code #234, "Invalid Protocol Identifier". 


Bit 2 of the Protocol Identifier also has particular significance in SNA environments: 


e "0" for SNA-to-non_SNA connections; or, 
e "1" for SNA-to-SNA connections. 


All Protocol Identifier code points are reserved except: 
x'CO® and x'Cl't for SNA-to-non SNA connections; and, 


@ 
° x'C2"', x'C3" and x'C6" for SNA-to-SNA connections (see "Logical Link Control (LLC) 
on SNA-to-SNA Connections" on page II-83). 


Note: When a virtual call is being established between two packet mode DTEs, the 
network does not act on any part of the Call User Data field. (text deleted.) 


6.2.2 Call Accepted and Call Connected Packets 


Figure 3 illustrates the format of CALL ACCEPTED and CALL CONNECTED packets. 


Bits 
8 7 6 5 4 3 2 dl 
Octet 
1 General format identifier (GFI) Logical channel group number 
2 Logical channel number 
3 
4 
| DTE address (see Note 2)* 
Facility length. 
n Facilities* 


¥—-These le aes are not mandatory in CALL ACCEPTED packets 
(see §-6.2.2). 


Figure 3. CALL ACCEPTED and CALL CONNECTED: Packet Format 
Notes to Figure 3: 
1. GFI - Coded 0X01 (modulo 8) or 0X10 (modulo 128). 
Where X = '0" on SNA-to-SNA connections; and, 


"0" or "1" on SNA-to-non SNA connections. 
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2. The figure is drawn assuming that a single address is present consisting of an odd 
number of digits. 


6.2.2.1 General Format Identifier 
On SNA-to-non SNA connections, bit 7 of octet 1 is equal to "0" unless the 'D’ bit 
mechanism defined in "Delivery Confirmation €D) Bit™ on page II-33 is used. 


CALL ACCEPTED packets and CALL CONNECTED packets must have bit 7 of octet 1 set to '0’ 
on SNA-to-SNA connections. 


6.2.2.2 Address Lensths Field 


Octet 4 contains field length indicators for called and calling DTE addresses. Bits 
4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 8, 7, 
6 and 5 indicate the length of the calling DTE address in semi-octets. Each address 
length indicator is binary coded and bit 1 or 5 is the low order bit of the indicator. 


The use of the Address Lengths field in CALL ACCEPTED packets is only mandatory when 
the Address field or the Facility Length field is present 


6.2.2.3 Address Field 
Octet 5 and the following octets consist of the called DTE address when present, then 
the calling DTE address when present. 


Each digit of an address is coded ina semi-~octet in binary coded. decimal with bit 5 or 
1 being the low-order bit of the digit. 


Starting from the high order digit, the address is coded in octet 5 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8, 7> 6 and 5. 


The Address field is rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field when necessary. 


(Text deleted. ) 


6.2.2.4 Facility Length Field 


Bits 6, 5, 4, 3, 2, and 1 of the octet following the Address field indicate the length 
of the Facility field in octets. The facility length indicator is binary coded and bit 
1 is the low order bit of the indicator. 

Bits 8 and 7 of this octet are unassigned and set to "00". 


The use of the Facility Length field in CALL ACCEPTED packets is only mandatory when 
the Facility field is present. 


6.2.2.5 Facility Field 


The Facility field is present only when the DTE is using an optional user facility 
requiring some indication in the CALL ACCEPTED and CALL CONNECTED packets. 


The coding of the Facility field is defined in "PROCEDURES AND FORMATS FOR OPTIONAL 
USER FACILITIES” on page II-69. 
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The Facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities. which are offered by the network. However, 
this maximum does not exceed 63 octets. | 


6.2.3 Clear Request and Clear Indication Packets | 


Figure 4 illustrates the format of CLEAR REQUEST and CLEAR INDICATION packets. 


Bits , 
8 7 6 5 q § 2 1 


Octet 
i General format identifier (CGFI) Logical channel group number , 


2 Logical channel number 

3 : Packet type identifier 
0 1 0 

4q | Clearing cause 


Diagnostic code 
(This field is mandatory on SNA-to-SNA Connections 
(see Appendix F)) 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 4. CLEAR REQUEST and CLEAR INDICATION: Packet Format 


6.2.3.1 Clearing Cause Field 


Octet 4 is the Clearing Cause field and contains the reason for clearing the call. 
The bits of the Clearing Cause field in CLEAR REQUEST packets are set to '0' by DTEs. 
(Text deleted). | | 


pees of the Clearing Cause field in CLEAR INDICATION packets is given in Table 
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Table II-9 — Coding of the Clearing Cause Field in 


CLEAR INDICATION packets 
8 7 6 5 4321 
DTE Originated 0000 0090 0 


Number busy 

Out of order 

Remote procedure error 

Reverse charging acceptance not subscribed* 
Incompatible destination 

Fast select acceptance not subscribed* 


Invalid facility request 
Access barred 
local procedure error 


Network congestion 
Not obtainable 
RPOA out of orderx 


HKHoaalreoo!]l oorrooe 
Oma | oro | ReOoOrOrFO 
ee ee ee 


0 0 
0 0 
00 
00 
0 0 
00 
0 0 
0 0 
00 
0 0 
0 0 
0 0 


* May be received only if the corresponding optional user facility 
1s used. 
DEC — decimal 


6.2.3.2 Diagnostic Code 


Octet 5 contains the Diagnostic Code and provides additional information on the reason 
for clearing the call. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for CLEAR REQUEST packets on 
SNA-to-SNA connections are specified in Table F-1. 


In a CLEAR INDICATION packet, if the Clearing Cause field indicates "DTE Originated", 
the Diagnostic Code is passed unchanged from the clearing DTE. If the clearing DTE has 
not provided a Diagnostic Code in its CLEAR REQUEST packet, the bits of the Diagnostic 
Code in the resulting CLEAR INDICATION packet are '0'. 


When a CLEAR INDICATION packet results from a RESTART REQUEST packet, the value of the 
Diagnostic Code will be that specified in the RESTART REQUEST packet or '0* when no 
Diagnostic Code has been specified in RESTART REQUEST packets 


When the Clearing Cause field does not indicate "DTE Originated,” the Diagnostic Code 
in a CLEAR INDICATION packet is network generated. Appendix E lists the codings for 
network generated diagnostics. The Diagnostic Code field is set to '0' when no 
specific additional information on the reason for clearing the call is supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code and Clearing 
Cause fields to a higher level. DTEs shall not refuse to accept the Cause field 
because the Diagnostic Code field contains an unspecified code combination. 


6.2.4 DTE and DCE Clear Confirmation Packets 


Figure 5 illustrates the format of DTE and DCE CLEAR CONFIRMATION packets. 
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| Bits a 
8 7 6 5 4 3 2 1 


Logical channel number 


Packet type identifier 
0 1 0 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 5. DTE and DCE CLEAR CONFIRMATION: Packet Format 
—66 3 CUDATA CAND INTERRUPT] PACKETS 


6.3.1 DTE and DCE Data Packets 


Figure 6 illustrates the format of DTE and DCE DATA packets: 


Bits 
8 7 6 5 & 3 2 1 
Octet 
1 General format identifier (GFI) Logical .channel group number 
Q D 0 1 
2 Logical channel number 
3 
n Call user data 
(Modulo 8) | 
Bits 
8 7 6 5 G 3 2 1 
Octet 
1 sa a format identifier (GFI) Logical channel group number 
D 1 0 
2 Logical channel number 
3 
4 
n User data 


(Modulo 128) 


"D' = Delivery confirmation bit (= "0" on SNA-to-SNA Connections). 
"M*' = More Data'‘bit 
*Q' = Qualifier bit 

Figure 6. DTE and DCE DATA: Packet Format 


6.3.1.1 Qualifier Bit 


Bit 8 of octet 1 is the Qualifier ('Q") bit. It is used on SNA-to-SNA connections to 
identify ‘Qualified’ ddadta packets as described in "Logical Link Control (CLLC) on 
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| SNA-to-SNA Connections” on page II-83. 


6.3.1.2 Delivery Confirmation Bit 


Bit 7 of octet 1 is the Delivery Confirmation bit. 


6.3.1.3 Packet Receive Sequence Number, Pr 


Bits 8» 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the Packet 
Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 when extended, is 
the low order bit. 


6.3.1.4 More Data Bit 


Bit 5 in octet 3, or bit 1 in octet 4 when extended, is the More Data mark C'M® bit) 
which: 


e "0" for no more data; and, 


° ="1" for more data. 


6.3.1.5 Packet Send Sequence Number, Ps 


Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended, are the 
Packet Send Sequence Number (Ps). Ps is binary coded and bit 2 is the low order bit. 


6.3.1.6 User Data Field 
Bits following octet 3, or octet 4 when extended, contain user data. 


| Note: The User Data field field must contain an integral number of octets. 
6.3.2 DTE and DCE Interrupt Packets 


6.3.2.1 SNA-tO-SNA Connections 


INTERRUPT packets are not allowed on SNA-to-SNA connections. 


6.3.2.2 SNA-to-non SNA Connections 


Figure 7 illustrates the format of DTE and DCE INTERRUPT packets. 
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Bits © w 4 _ 
8 7 6 5 4 3 2 1 
Octet : 
1 General format identifier (GFI) Logical channel group number 
2 Logical channel number 
3 Packet type identifier 
0 0 1 0 0 | 1 1 
4 | Interrupt user data 


Note: GFI — Coded 0X01 (modulo 8) or 0X10 (modulo 128). 


Figure 7. DTE and DCE INTERRUPT: Packet Format 


6.3.2.3 Interrupt User Data Field 


Octet 4 contains user data. 


6.3.3 DTE and DCE Interrupt Confirmation Packets 


6.3.3.1 SHA-to-SNA Connections 


INTERRUPT CONFIRMATION packets are not allowed on SNA-to-SNA connections. 


6.3.3.2 SNA-to-non SNA Connections 


Figure 8 illustrates the format of DTE and DCE INTERRUPT CONFIRMATION packets. 


Bits 
8 7 6 5 4 3 2 : 1 


General format identifier (CGFI) Logical channel group number 


Octet 
j 


2 | | Logical channel number 


3 Packet type identifier 
1 0 0 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 8. DTE and DCE INTERRUPT CONFIRMATION: Packet Format 


6.4 DATAGRAM AND DATAGRAM SERVICE SIGNAL PACKETS 


DATAGRAM and DATAGRAM SERVICE SIGNAL packets are not allowed in IBM SNA X.25 DTEs. 


(Text deleted). 
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6.5 FLOW CONTROL AND RESET PACKETS 


6.5.1 DTE and DCE Receive Ready (RR) Packets 


Figure 9 illustrates the format of DTE and DCE RECEIVE READY packets. 


Bits 
8 7 6 5 4 3 2 1 
Octet 
1 General format identifier (GFI)}| Logical channel group number 
0 0 0 1 
2 Logical channel number 
3 Packet type identifier 
0 0 0 
(Modulo 8) 
Bits ; 
8 7 6 5 & 3 2 j 
Octet 
l penener eon el al ia Logical channel group number 
2 | Logical channel number 
Packet type identifier 
0 0 0 
4 


(Modulo 128) 


Figure 9. DTE and DCE RECEIVE READY: Packet Format 


6.5.4.1 Packet Receive Sequence Number, Pr 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the Packet 


Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 when extended, is 
the lew order bit. 


6.5.2 DTE and DCE Receive Not Ready (RNR) Packet 


olor ce 10 on page II-60 illustrates the format of DTE and DCE RECEIVE NOT READY 
packets. : | 7 : 
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Bits: 
8 7 6 5 4 3 2 1 
Octet 
1 canara rena ost onan (GFI)] Logical channel group number 
1 3 
; | 
(Modulo 8) 
Bits 
8 7 6 5 —&g 3 2 1 
Octet 
1 
2 
3 
4 


C(Modulo 128) 


Figure 10. DTE and DCE RECEIVE NOT READY: Packet Format 


6.5.2.1 Packet Receive Sequence Number, Pr 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended; are the Packet 
Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 when extended, is 
the low order bit. 


6.5.3 Reset Request and Reset Indication Packets 


Figure 11 illustrates the format of RESET REQUEST and RESET INDICATION packets. 


Bits | 
8 i 7 6 5 & 3 2 1 
Octet . 

1 General format identifier (GFI) Logical channel group number 
2 7 Logical channel number 
3 Packet type identifier 

0 0 0 1 1 1 1 
& Resetting cause 
5 Diagnostic code 


(This field is mandatory on SNA-to-SNA Connections 
(see Attachemt F)) 


(Text deleted. ) 
Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure ll. RESET REQUEST and RESET INDICATION: Packet Format | 
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6.5.3.1 Resetting Cause Field 


Octet 4 is the Resetting Cause field and contains the reason for the reset. 


The bits of the Resetting Cause field in RESET REQUEST packets must be set to '0' by 
DTEs. 


(Text deleted. ) 


The coding of the Resetting Cause field in RESET INDICATION packets is given in Table 
II-11. 


Table II-11 —- Coding of the Clearing Cause field 
in RESET INDICATION packets 


DTE Originated 


Out of order 

Remote procedure error 
Local procedure error 
Network congestion 

Remote DTE operational* 
Network operational* 
Incompatible destination* 


KM aacoaooo!] oe 

=e kh —e— 2 — 
COrROrKFOO!] GO] Ww 
— i — 2 2 
to de er er pr eer | > | 


eoooonoc°ce oS oo 
ooo oo S&S & Come J 
CQooo00oocsc Oo 


*¥ Applicable to permanent virtual circuits only. 
DEC — decimal 


6.5.3.2 Diagnostic Code 


Octet 5 is the Diagnostic Code field (mandatory on SNA-to-SNA connections) and 
contains additional information on the reason for the reset. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for RESET REQUEST packets on 
SNA-to-SNA connections are shown in Table F-1. 


In a RESET INDICATION packet, if the Resetting Cause field indicates "DTE Originated”, 
the Diagnostic Code has been passed unchanged from the remote DTE. If the DTE 
requesting a reset has not provided a Diagnostic Code in its RESET REQUEST packet, the 
bits of the Diagnostic Code in the resulting RESET INDICATION packet are ‘0°. 


If a RESET INDICATION packet results from a RESTART REQUEST packet, the value of the 
Diagnostic Code will be that specified in the RESTART REQUEST, or '0' in the case where 
no Diagnostic Code has been specified in RESTART REQUEST packets. 


If the Resetting Cause field does not indicate "DTE Originated”, the Diagnostic Code 
in RESET INDICATION packets is network generated. Appendix E lists the codings for. 
network generated diagnostics. The Diagnostic Code field is set to '0' when no 
specific additional information on the reason for the reset is supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code and Resetting 
Cause fields to a higher layer. DTEs shall not refuse to accept the Cause field 
because the Diagnostic Code field contains an unspecified code combination. 


6.5.4 DTE and DCE Reset Confirmation Packets 


Baie 12 on page II-62 illustrates the format of DTE and DCE RESET CONFIRMATION 
packets. 
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a mY eS Bits 7 , 
8 : 7 6 3 5 G4 £43 2 1 
Octet : . 
1 General Fovnat: identi fier (GFI) Logical channel group number 
2 . 2 7 : logiesl channel number : a 
3 


Packet type identifier 
0 1 1 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 12. DTE and DCE RESET CONFIRMATION: Packet Format 
6.6 RESTART. PACKETS | 


6.6.1 Restart Request and Restart Indication Packets 


Figure 13 illustrates the format of RESTART REQUEST and RESTART INDICATION packets. 
| | Bits 


8 7 6 5 +& 3 2 1 
Octet 
1 General format identifier (GFI) Logical channel enone es 
0 0 . 
3 
4 
5 


Diagnostic code 
(This field is mandatory on SNA-to-SNA Connections 
(see Appendix F)) 


(Text deleted. ) 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 13. RESTART REQUEST and RESTART INDICATION: Packet Format 


6.6.1.1 Restarting Cause Field 


Octet 4 is the Restarting Cause field and contains the reason for the restart 


The bits of the Restarting Cause field in RESTART REQUEST Pease are set to 0" by IBM 
SNA X.25 DTEs. (Text deleted). 


The coding of the Restarting Cause field in RESTART INDICATION packets is given in 
Table II-12. 
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Table II~-12 — Coding of the Restarting Cause field 
in RESTART INDICATION packets 


DEC — decimal 


6.6.1.2 Diagnostic Code 


Octet 5 contains the Diagnostic Code which provides additional information on the 
reason for the restart. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for RESTART REQUEST packets on 
SNA-to-SNA connections are given in Table F-1. The Diagnostic Code is passed to the 
corresponding DTEs as the Diagnostic Code of a RESET INDICATION packet on permanent 
virtual circuits or a CLEAR INDICATION packet on virtual calls. 


The coding of the Diagnostic Code field in a RESTART INDICATION packet is given in 
Appendix E. The contents of the Diagnostic Code field is set to '0" when no specific 
additional information on the reason for the restart is supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code field to a 
higher layer. DTEs shall not refuse to accept the Cause field because the Diagnostic 
Code field contains an unspecified code combination. 


6.6.2 DTE and DCE Restart Confirmation Packets 


Figure 14 illustrates the format of DTE and DCE RESTART CONFIRMATION packets. 


Bits 
8 7 6 5 4 3 2 1 
Octet 
1 General format identifier (GFI)]| Logical channel group noe ee 
| 0 0 0 

2 Logical channel number 

0 0 0 
3 Packet type identifier 

1 1 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 14. DTE and DCE RESTART CONFIRMATION: Packet Format 


6.7 DIAGNOSTIC PACKETS 


Figure 15 on page II-64% illustrates the format of DIAGNOSTIC packets. 
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he | oo Bits | 
8 7 6 5 4 3 2 1 


Octet 
1 General format identifier (GFI)| Logical channel group number 
0 0 
; 3 | 
3 
4 
5 
: | Diagnostic explanation (see Note 2) | 
n 


Figure 15. DIAGNOSTIC: Packet Format 
Notes te Figure 15: 
1. GFI - Coded 0001 (modulo 8) or 0010 Cmodulo 128). 


2. The diagnostic explanation field is required to be an integral number of octets in 
length. 


6.7.1 Diagnostic Code Field 


Octet 4 contains the diagnostic code and provides information on the error condition 


‘that resulted in the transmission of the DIAGNOSTIC packet. Diagnostic Codes are 
given in Appendix E. 


6.7.2 Diagnostic Explanation Field 


When the DIAGNOSTIC packet is issued, by DCEs, as a result of receiving an erroneous 
packet from the DTE (see Table C-1), this field contains the first three octets of 
header information from the erroneous DTE packet. If the packet contains less than 3 
octets, this field contains whatever bits were received. 


When the DIAGNOSTIC packet is issued as a result of a DCE time-out (see Table D-1), the 
Diagnostic Explanation field contains 2 octets coded as follows: 


Bits 8» 7, 6 and 5 of the first octet contain the General Format Identifier for the 
DTEZBDCE interface. 


e Bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are x'000' for 
expiration of time-out T10; and, give the identifier of the logical channel on 
which the time-out occurred for expiration of time-out T12 or T13. 


6.8 PACKETS REQUIRED FOR OPTIONAL USER FACILITIES 
6.8.1 BITE Reject (REJ) Packet for the Packet Retransmission Facility 


The packet retransmission facility is not used in SNA environments. Therefore, DTE 
REJECT packets are not generated by IBM SNA X.25 DTEs. 


(Text deleted). 
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6.8.2 Call Set-up and Clearing Packets for the Fast Select Facilities 


6.8.2.1 SNA-to-SNA Connections 


The possible use of Fast Select facilities on SNA-to-SNA connections is a subject for 
further study. 


6.8.2.2 SNA-to-non_SNA Connections 


Figure 16 illustrates the format of CALL REQUEST and INCOMING CALL packets used in 
conjunction with the Fast Select facility and Fast Select Acceptance facility 
described in "Fast Select" on page II-75 and "Fast Select Acceptance™ on page II-76. 


The description in “Call Request and Incoming Call Packets” on page II-50 applies 
here, except that the call user data field has a maximum length of 128 octets. 


Note: At present, some networks require the call user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" on 
page JI-24%, Note 2). 


Bits 
8 7 6 5 4 m) 2 j 


General format identifier (GFI) Logical channel group number 


Octet 
1 


2 Logical channel number 
3 Packet type identifier 
0 0 0 1 0 1 1 

: | DTE address (see Note 2) 

, 0 

es 
Facilities 

n Call user data (see Notes 3 and 4) 


Figure 16. CALL REQUEST and INCOMING CALL: Packet Format for the Fast Select 
facility 


Notes to Figure 16: 
1. GFI'- Coded 0X01 (modulo 8) or 0X10 (modulo 128). 


2.. The figure is drawn assuming a single address is present consisting of an odd 
number of digits. 


3. Bits 8 and 7 of the first octet of the call user data field may have particular 
Significance (see "Call Request and Incoming Call Packets” on page II-50). 


G4. Maximum length of the call user data field is 128 Octets. 
Figure 17 on page II-66 illustrates the format of CALL ACCEPTED and CALL CONNECTED 
packets used in conjunction with the Fast Select facility and Fast Select Acceptance 


toed ey described in "Fast Select” on page II-75 and "Fast Select Acceptance” on page 
II-76. 
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Bits 


8 a oe 5 4 3. 2 1 


—- Logical channel group number 
2 — | booleat channel number ih ian 
3 Packet type identifier 

«0 0 0 0 1 1 1 | 1 
‘. 


: : DTE address (see Note 2) 


Facilities — 


n | Call user data (see Notes 3 and 4) 


Figure 17. oes ACCEPTED and CALL CONNECTED: Packet Format for the Fast Select 
, acility 


Notes to Figure 17: 
1 GFI - Coded 0X01 Cmodulo 8) or 0X10 (modulo 128). 


2. The figure is drawn assuming a single address is present consisting of an odd 
number of digits. 


3. Bits 8 and 7 of the first octet of the call user data field may have particular 
Significance (see "Call Request and Incoming Call Packets" on page II-50). 


4. Maximum length of the call user data field is 128 Octets. 


The description in "Call Accepted and Call Connected Packets" on page II-52 applies 
here and, in addition, the called user data field may be present and has a maximum 
length of 128 octets. The address lengths field and facility Length field are 


mandatory. | 


Note: At present, some networks require the called user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" on 
page II-24, Note 2). 


If the called user data field is present, the use and format of this field is 
determined by bits 8 and 7 of the first octet of this field (see Note below). 


If bits 8 and 7 of the first octet of the called user data field are '00', a portion of 
the called user data field is used for protocol identification in accordance with 
other Recommendations. 


If bits 8 and 7 of the first octet of the called user data field are "01", a portion of 
the calied user data field is used for protocol identification in accordance with 
specifications of Administrations. 


If bits 8 and 7 of the first octet of the called user data field are '10', a portion of 
the called user data field may be used for protocol identification in accordance with 
specifications of international user bodies. 


If bits 8 and 7 of the first octet of the called user data field are '"1ll', no 


es are placed on the use by the DTE of the remainder of the called user data 
ield. | .* | : 


Users are cautioned that if bits 8 and 7 of the first octet of the called user data 
field have any value other than '11', a protocol may be identified that is implemented 
within public data networks. 
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Note: When a virtual call is being established between two packet mode DTEs, the 
network does not act on any part of the called user data field. 


Figure 18 illustrates the format of CLEAR REQUEST and CLEAR INDICATION packets used in 
conjunction with the Fast Select facility and Fast Select Acceptance facility 
described in "Fast Select” on page II-75 and "Fast Select Acceptance" on page II-76. 


Bits 
8 7 6 5 4 3 2 l 
Octet 

1 General format identifier (CGFI) Logical channel group number 
2 Logical channel number 
3 Packet type identifier 

0 0 0 1 0 0 1 1 
a a 
a a 
6 Calling DTE address length Called DTE address length 


. DTE address (see Note 2) 


Facilities 


n Call user data (see Notes 3) 


Figure 18. CLEAR REQUEST and CLEAR INDICATION: Packet Format for the Fast 
Select facility 


Notes to Figure 18: 
1. GFI - Coded 0X01 Cmodulo &) or 0X10 (modulo 128). 


2. The figure is drawn assuming a single address is present consisting of an odd 
number of digits. 


3. Maximum length of the call user data field is 128 octets. 
Description of the clearing cause field and the diagnostic code field in "Clear 
Request and Clear Indication Packets" on page I1-54 apply here. In addition the 
following fields may follow the diagnostic code field and in such cases the use of the 
diagnostic code field its mandatory. 
1. Address lengths field 
Octet 6 consists of field length indicators for the called and calling DTE 
addresses. Bits 4, 3, 2 and 1 indicate the length of the called DTE address in 
semi-octets. Bits 8, 7, 6 and 5 indicate the length of the calling DTE address in 


semi~octets. Each address length indicator is binary codec. and bit 1 or 5 is the 
low order bit of the indicator. 


Note: This field is coded with all "0's. Other codings are for further study. 
2. Address field 
Note: Pending the further study indicated above, this field is not present. 


3. Facility length field 
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Bits 6, 5, 4, 3, 2 and 1 of the octet following the address field indicate the 
length of the facility field in octets. The facility length indicator is binary 
coded and bit 1 is the low order bit of the indicator. 


Bits 8 and 7 of this octet are unassigned and set to 0. 


Note: This field is coded with all '0's. Other codings are for further study. 
Facility field a a 


Note: Pending the further study indicted above, this field Vecwot present. 


Clear user data field | | 
Following the facility field, the clear user data field may be present and has a 
maximum length of 128 octets. 


Note: At-present, some networks require the clear user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" 


on page II-24%, Note 2). 
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7.0 PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES 
7.1 PROCEDURES FOR OPTIONAL USER FACILITIES ASSOCIATED WITH VC SERVICES 


7.1.1 Extended Packet Sequence Numbering 


Extended Packet Sequence Numbering is an optional user facility agreed upon for a 
period of time. It applies in common to all logical channels at the DTE/DCE interface. 


This user facility, if subscribed to, provides sequence numbering of packets performed 
modulo '128'. In the absence of this facility, the sequence numbering of packets is 
performed modulo ‘8’. 


7.1.2 WNon-Standard Default Window Sizes 


Non-standard Default Window Sizes is an optional user facility agreed upon for a 
period of time. The ability to select this facility must be provided by IBM SNA X.25 
DTEs. This user facility, if subscribed to, provides for the selection of default 
window sizes from the List of window sizes supported by the network. Some 
Administrations may constrain the default window sizes to be the same for each 
direction of data transmission across the DTE/DCE interface. In the absence of this 
facility, the default window sizes are two (2). 


Values other than the default window sizes may be negotiated for virtual calls, ona 
per call basis, by means of the Flow Control Parameter Negotiation facility (see "Flow 
Control Parameter Negotiation" on page JI-73), which is recommended for implementation 
by IBM SNA X.25 DTEs. Values other than the default window sizes may be agreed upon 
for a period of time for each permanent virtual circuit. (Text deleted). 


7.1.3 Default Throughput Classes Assignment 


Default Throughput Class Assignment is an optional user facility agreed upon for a 
period of time. This user facility, if subscribed to, provides for the selection of 
default throughput classes from the list of throughput classes supported by the 
network. Some Administrations may constrain the default throughput classes to be the 
same for each direction of data transmission. In the absence of this facility, the 
default throughput classes correspond to the user class of service of the DIE (see 
"Coding of Throughput Class Negotiation Facility" on page II-81) but do not exceed the 
maximum throughput class supported by the network. 


The default throughput classes are the maximum throughput classes which may be 
associated with any virtual call at the DTE/DCE interface. Values other than the 
default throughput classes may be negotiated for a virtual call by means of the 
Throughput Class Negotiation facility (see "Throughput Class Negotiation™ on page 


II-74). Values other than the default throughput classes may be agreed upon for a 
period of time for each permanent virtual. circuit. 


7.1.4 Packet Retransmission 

The packet retransmission facility is not used in SNA environments. 
(Text deleted). 

7.1.5 Incoming Calls Barred 


Incoming Calls Barred is an optional user facility agreed upon for a period of time. 
This facility applies to all logical channels at the DTE/DCE interface used for 
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virtual calls (Text deleted). This user facility, if subscribed to, prevents virtual. 
calls (text deleted) from being presented to the DTE. The DTE may originate outgoing 
virtual calls Ctext deleted) only. 


oe ‘ogieal channels used for Sip tual: calls. hataiH their full duplex capability. 
(Text deleted). 


7.1.6 sutaoing Calls Barred 


Outgoing Calls Barred is an optional user facility agreed upon for a period of time. 
This. facility applies to all logical channels” at the ee interface used for 
virtual calls (text deleted). | 2 * 


This user facility, if subscribed to, prevents the DCE from accepting outgoing virtual 
delet Bae deleted) from the DTE. DTEs may receive incoming virtual calls (text 
eleted). | | ) | 


Note: vogieni channels used for virtual calls retain their full duplex capability. 


7.1.7 One-Way Logical Channel Outgoing — 


One-way Logical Channels Outgoing is an optional user facility agreed upon for a 
period of time and is recommended for IBM SNA X.25 DTEs that support multiple virtual 
circuits. This user facility, if subscribed to, restricts logical channel use xe 
originating gurgoing: virtual calls (text deleted) only. 


Note: <A logical channel used 5% virtual calls retains its full duplex capability. 
(Text deleted). | | 


The rules accordens to which logical channel group numbers and logical channel numbers 


can be assigned to one-way outgoing logical channels for virtual calls are given in 
Appendix A. 


Note: If all the logical channels for virtual calls (text deleted) are one-way 
outgoing at a DTE/DCE interface, the effect is equivalent to the ppeemEne Calls Barred 
racy (see ey Calls Barred” on page II-69). 


7.1.8 One-Way Logical Channel Incoming 


One-way Logical Channels Incoming is an optional user facility agreed upon for a 
period of time. This user facility, if subscribed to, restricts logical channel use 


to receiving incoming virtual calls (text deleted) only. This facility is recommended 
for IBM SMA X.25 DTEs that support multiple virtual circuits. 


Note: A legical channel used for virtual calls retains its full duplex capability. 


The rules according to which logical channel group numbers and logical channel numbers 
can be assigned to one-way logical channels for virtual calls are given in Appendix A. 


Note: If all logical channels for virtual calls are one-way incoming at a DTE/DCE 
interface, the effect is Bau veTene to the Outgoing Calls Barred Facility (see 


"Outgoi ing Calls Barred™). 
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7.:.% Closed User Group 


Closed User Group is an optional user facility agreed upon for a period of time for 
virtual calls (text deleted). This facility, if subscribed to, enables the DTE to 
belong to one or more closed user groups, and is recommended for IBM SNA X.25 DTEs. A 
closec’ user group permits the DTEs belonging to the group to communicate with each 


other, but precludes communication with all other DTEs. 


The calling/source DTE should specify the closed user group selected for a virtual 
call Ctext deleted) using the optional user facility parameters (see "Coding of Closed 
User Group Facility™ on page II-79) in the CALL REQUEST (text deleted) packet. 


The closed user group selected for a virtual call (text deleted) will be indicated to a 
called/destination DTE using the optional user facility parameters (see "Coding of 
Clesed User Group Facility" on page II-79) in the INCOMING CALL (text deleted) packet. 


When a DTE only belongs to one closed user group or when the virtual call (text 
deleted) is associated with the DTE's preferential closed user group, this indication 
may not be present in the CALL REQUEST or INCOMING CALL (text deleted) packet. 


IBM SNA X.25 DTEs that support a single CLOSED USER GROUP require no coding in the 


facilities field when the PSDN supports the assignment of a default user group. 


7.1.10 Closed User Group with Outgoing Access 


Clesed User Group with Outgoing Access is an optional user facility agreed upon for a 
period of time for virtual calls (text deleted). This facility, if subscribed to, 
enables the DTE to belong to one or more closed user groups (Cas in "Closed User Group™) 
and to originate virtual calls (text deleted) to DTEs in the open part of the network 
and to DTEs having the incoming access capability. This facility is recommended for 
IBM SNA X.25 DTEs that support multiple virtual circuits. 


The procedures for using this facility are the same as those given in "Closed User 
Group." However, the optional user facility parameters may not be present when 
originating virtual calls (text deleted) to DTEs in the open part of the network or to 
DI€s having the incoming access s capability. 


7.4.11 Closed User Group with Incom:ng Access 


Clesed User Group with Incoming Access is an optional user facility agreed upon for a 
pertod of time for virtual calls (text deleted). This facility, if subscribed to, 
enables the DTE to belong to one or more closed user groups (as in "Closed User Group™) 
and to receive incoming calls (text deleted) from DTEs in the open part of the network 
and from DTEs having the outgoing access capability. 


The procedures for using this facility are the same as those given in "Closed User 
Group. " However, the optional user facility parameters may not be present when 
receiving incoming calls (text deleted) from DTEs in the open part of the network or 
from DTEs having the outgoing access capability. This facility is recommended for IBM 
SHA X.25 DTEs that support multiple virtual circuits. 


7.1.12 Incoming Calls Barred Within a Closed User Group 


Incoming Calls Barred within a Closed User Group is an optional user facility agreed 
upon for a period of time. This user facility, if subscribed to for a given closed 


user group, permits the DTE to originate virtual calls (text deleted) to DTEs in this 


closed user group, but precludes the EECePr a0 of incoming calls (text deleted) from 
other DTEs in this closed user group. 


The procedures for using this facility. are the same as those given in "Closed User 
Group, yp" Closed User Group with Outgoing Access" and "Closed User Group with Incoming 
Access. , 
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7.1.13 Outgoing Calls Barred within a Closed User Group 


Outgoing Calls: Barred within a Closed User Group is an optional facility agreed upon 
for a period of time. This user facility, if subscribed to for a given closed user 
group, permits the DTE to receive virtual calls (text deleted) from other DTEs in this 
closed user group, but prevents the DTE from originating virtual calls (text deleted). 
to other DTEs in this closed user group. 


The procedures for using this facility are the same as those given in "Closed User 


Group™ on page II-71, "Closed User Group with Outgoing Access™ on page II-71 and 
"Closed User Group with Incoming Access" on page II-71. 


7.1.14 Bilateral Closed User Group 


Bilateral Closed User Groups are not supported in SNA environments. 


CText deleted). 


7.1.15 Bilateral Closed User Group with Outgoing Access 


Bilateral Closed User Groups with Outgoing Access are not supported in SNA 
environments. 


(Text deleted). 


7.1.16 Reverse Charging 


Reverse Charging is an optional user facility which can be requested by a DTE for a 
given virtual call (text deleted) (see "Coding of Reverse Charging Facility” on page 
II-79). This facility is recommended for IBM SNA X.25 DTEs. 


7.1.17 Reverse Charging Acceptance 


Reverse Charging Acceptance is an optional user facility agreed upon for a period of 
time. 


This user facility, if subscribed to, authorizes the DCE to transmit to the DTE 
incoming calls (text deleted) which request the Reverse Charging facility. In the 
absence of this facility, the DCE will not transmit to the DTE incoming calls (text 
deleted) which request the Reverse Charging facility. This facility is recommended 
for IBM SNA X.25 DTEs. 


7.1.18 RPOA Selection 


RPOA (Recognized Private Operating Agency) selection is an optional user facility 
which can be requested by a DTE for a given virtual call (text deleted). 


This user facility, when requested, provides for the user specification by the 
calling/source DTE of a particular RPOA transit network through which the call (text 
deleted) is to he routed internationally, when more that one RPOA transit network 


ane at an international gateway (see "Coding of RPOA Selection Facility” on page 


7.2 PROCEDURES FOR OPTIONAL USER FACILITIES ONLY AVAILABLE WITH VC SERVICES 
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7.2.1 Non-Standard Default Packet Sizes 


Non-standard Default Packet Sizes is an optional user facility agreed upon for a 
period of time. The ability to select this facility must be provided by IBM SNA X.25 
DTEs. This facility, if subscribed to, provides for the selection of default packet 
sizes from the list of packet sizes supported by the network. Some network 
Administrations may constrain packet sizes to be the same for each direction of data 
transmission across the DTE/DCE interface. In the absence of this facility, default 
packet sizes are '128' octets. 


Note: In “Non-Standard Default Packet Sizes,” the term "packet sizes" refers to the 
maximum User Data field lengths of DCE DATA and DTE DATA packets. 


Values other than the default packet sizes may be negotiated for a virtual call, ona 
per call basis, by means of the flow control parameter negotiation facility (see "Flow 
Control Parameter Negotiation"), which may be implemented in IBM SNA X.25 DTEs. 
Values other than the default packet sizes may be agreed upon for a period of time for 
each permanent virtual circuit. 


7.2.2 Flow Control Parameter Negotiation 


Flow Control Parameter Negotiation is an optional user facility agreed upon for a 
period of time which can be used by a DTE for virtual calls. The ability for the DTE 
to select this facility is recommended for IBM SNA X.25 DTEs. This facility, if 
subscribed to, permits negotiation, on a per call basis, of flow control parameters. 
The flow control parameters considered are the packet and window sizes at the DTE/DCE 
interface for each direction of data transmission. 


Note: In "Flow Control Parameter Negotiation," the term "packet sizes" refers to the 
maximum User Data field lengths of DCE DATA and DTE DATA packets. 


In the absence of the Flow Control Parameter Negotiation facility, the flow control 
parameters to be used at a particular DTE/DCE interface are the default packet sizes 
(see "Non-Standard Default Packet Sizes") and the default window sizes (see 
"Non-Standard Default Window Sizes" on page II-69). 


When the calling DTE has subscribed to the Flow Control Parameter Negotiation 
facility, it may separately request packet sizes and window sizes for each direction 
of data transmission (see "Coding of the Flow Control Parameter Negotiation Facility" 

on page II-80). If a particular window size 1s not explicitly requested ina CALL 
REQUEST packet, the DCE will assume that the default window size was requested. Ifa 
particular packet size 1s not explicitly requested, the DCE will assume that the 
default packet size was requested. 


When a called DTE has subscribed to the Flow Control Parameter Negotiation facility, 
each INCOMING CALL packet indicates the packet and window sizes from which negotiation 
starts. No relationship needs to exist between the packet sizes (P) and window sizes 
(W) requested in the CALL REQUEST packet and those indicated in the INCOMING CALL 
packet.’ The called DTE may request Window and packet sizes with facilities in the CALL 
ACCEPTED packet. The only valid facility requests in the CALL ACCEPTED packet, as a 
function of the facility indications in the INCOMING CALL packet, are given in Table 
II-13. If the Facility request is not made in the CALL ACCEPTED packet, the DTE is 
assumed to have accepted the indicated values (regardless of the default values). 
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TABLE II-13 — Valid facility: peaticst« in CALL ACCEPTED packets in | 
response to facility indications in INCOMING CALL packets 


—_ Facility Indication 
W Cindicated) 2 2 — 3 
| W Cindicated) = 1 
P (indicated) 2128 | 
| P Cindicated) < 128 


When the calling DTE has subscribed to the Flow Control Parameter Negotiatior 
facility, every CALL CONNECTED packet indicates the packet and window sizes used at 
the DTE/DCE interface for the call. The only valid facility indications in the CALL 
CONNECTED packet, as a function of the facility requests in the CALL REQUEST packet, 
are given in Table II-14. 


Valid Facility Request 


Wl Cindicated) > W Crequested) 2 2 
W Crequested) = 1 or 2 


P Cindicated) > P Crequested) 2 128 
128 2P (Crequested) 2 P Cindicated) 


TABLE II-14 — Valid facility indications in CALL CONNECTED packets in 
response to facility request in CALL REQUEST packets 


Facility Request Valid Facility Indication | 


requested) W Crequested) 2 W Cindicated) 2 
requested) W Cindicated) = 1 or 2 


requested) P Crequested) 2 P (indicated) > 128 
requested) 128 =P Cindicated) 2 P Crequested) 


The network may have constraints requiring the flow control parameters used for a call 
to be modified before indicating them to the DTE in the INCOMING CALL packet or CALL 


CONNECTED packet; e.g., the ranges of parameter values available on various networks 
may differ. | 


Window and packet sizes need not be the same at each end of a virtual call. 


The role of the DCE in negotiating the flow control parameters may be network 
dependent. | 


7.2.3 Throughput Class Negotiation 


Throughput class negotiation is an optional user facility agreed upon for a period of 
time which can be used by a DTE for virtual calls. This facility, if subscribed to, 
permits negotiation, on a per call basis, of the throughput classes; and, should be 
supported by IBM SNA X.25 DTEs that support multiple virtual circuits. The throughput 
classes are considered independently for each direction of data transmission. 


Default values are agreed upon between the DTE and the Administration (see "Default 
Throughput Classes Assignment" on page II-69). The default values correspond to the 


maximum throughput classes which may be associated with any virtual call at the 
DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput Class Negotiation facility, it 
may separately request the throughput classes of the virtual calls in the CALL REQUEST 
packet (see "Coding of Throughput Class Negotiation Facility” on page II-81). If 


particular throughput classes are not requested, the DCE will assume the default 
values. | 


When a called DTE has subscribed to the Throughput Class Negotiation facility, each 
INCOMING CALL packet indicates the throughput classes from which negotiation may 
starts. Fhese throughput classes are lower or equal to the ones selected at the 
calling DTE/DCE interface, either explicitly, or by default if the calling DTE has not 
subscribed to the Throughput Class Negotiation facility or has not explicitly 
requested throughput class values in the CALL REQUEST packet. These throughput 
classes indicated to the called DTE will also not be higher than the default 
throughput classes, respectively, for each direction of transmission, at the calling 
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and the called DTE/YDCE interfaces. They may be further constrained by internal 
limitations of the network. 


The called DTE may request with a facility in the CALL ACCEPTED packet the throughput 
classes that should finally apply to the virtual call. The only valid throughput 
classes in the CALL ACCEPTED packet are lower than or equal to the ones (respectively) 
indicated in the INCOMING CALL packet. If the called DTE does not make any throughput 
class facility request in the CALL ACCEPTED packet, the throughput classes finally 
applying to the virtual call will be the ones indicated in the INCOMING CALL packet. 


If the called DTE has not subscribed to the Throughput Class Negotiation facility, the 
throughput classes finally applying to the virtual call are less than or equal to the 
ones selected at the calling DTE/DCE interface, and less than or equal to the default 
values defined at the called DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput Class: Negotiation facility, 
oY ed ope ee eta packet will indicate the throughput classes finally applying to 
e virtual call. 


When neither the calling DTE nor the called DTE has subscribed to the Throughput Class 
Negotiation facility, the throughput classes applying to the virtual call will not be 
higher than the ones agreed as defaults at the calling and called DTE/DCE interfaces. 
They may be further constrained to lower values by the network, e.g., for 
international service. 


Note: 


1. {Since both Throughput Class Negotiation and Flow Control Parameter Negotiation 
(see "Flow Control Parameter Negotiation” on page II-73) facilities can be applied 
i CN ele ai the achievable throughput will depend on how users manipulate 
he " bit. | 


2. Users are cautioned that the choice of too small a Window and packet size at a 
DTE/DCE interface (made by use of the Flow Control Parameter Negotiation facility?) 
may adversely affect the attainable throughput class for a virtual call. This is 
likewise true of flow control mechanisms adopted by the DTE to control data 
transmission from the DCE. 


7.2.% Fast Select 


7.2.%.1 SNA-tO-SNA Connections 


The possible use of the Fast Select facility on SNA-to-SNA connections is a subject 
for further study. 


7.2.-%.2 SNA-to-non_SNA Connections 


Fast select is an optional user facility which may be requested by a DTE for a given. 
virtual call. 


DTEs can request the fast select facility on a per call basis by means of an 
appropriate request (see "Coding of Fast Select Facility™ on page II-82) in a CALL 
REQUEST packet using any logical channel which has been assigned to virtual calls. 


The fast select facility, if requested in the CALL REQUEST packet and if it indicates 
no restriction on response, allows this packet to contain a call user data field of up 
to 128 octets and authorizes the DCE to transmit to the DTE, during the DTE waiting 
state, a CALL CONNECTED packet with a called user data field of up to 128 octets ora 
CLEAR INDICATION packet with a clear user data field of up to 128 octets. 


The fast select facility, is requested in the CALL REQUEST packet and if it indicates 
restriction on response, allows this packet to contain a call user data field of up to 
128 ectets and authorizes the DCE to transmit to the DTE, during the DTE waiting state, 
a CLEAR INDICATION packet with a clear user data field of up to 128 octets; the DCE 
would not be authorized to transmit a CALL CONNECTED packet. 
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Where a DTE requests the Fast Select facility in a CALL REQUEST packet, the INCOMING 
CALL packet should be only delivered to the called DTE if that DTE has subscribed to 
the fast select acceptance facility (see "Fast Select Acceptance"). | 


If the called DTE has subscribed to the fast select acceptance facility, it will be 
advised that the fast select facility, and an indication of whether or not there is a 
restriction on the response, has been requested through the inclusion of the 
appropriate facility in the INCOMING CALL packet. | : 


If the called DTE has not subscribed to the fast select acceptance facility, an 
INCOMING CALL packet with the fast select facility requested will not be transmitted 
and a CLEAR INDICATION packet with the cause "Fast select acceptance not subscribed" 
will be returned to the calling DTE. 


The presence of the fast select facility indicating no restriction on response in an 
INCOMING CALL packet permits the DTE to issue as a direct response to this packet a 
CALL ACCEPTED packet with a called user data field of up to 128 octets or a CLEAR 
REQUEST packet with a clear user data field of up to 128 octets. 


The presence of the fast select facility indicating restriction on response in an 
INCOMING CALL packet permits the DTE to issue as a direct response to this packet a 
CLEAR REQUEST packet with a clear user data. field of up to 128 octets; the DTE would 
not be authorized to send a CALL ACCEPTED packet. 


The possibility to send a CLEAR REQUEST packet with a clear user data field up to 128 
octets at any time instead of just in the DCE Waiting state (p3) is for further study. 


Note: The call user data field, the called user data field and the clear user data 
field will not be fragmented for delivery across the DTE/DCE interface. 


The significance of the CALL CONNECTED packet and the CLEAR INDICATION packet with the 
cause "DTE originated” as a direct response to the CALL REQUEST packet with the fast 
select facility is that the CALL REQUEST packet with the data field has been received 
by the called DTE. 


All other procedures of a call in which the fast select facility has been requested are 
the same as those of a virtual call 


If a fast select CLEAR REQUEST packet with a non-zero Address Length field or Facility 
Length field is received, the DCE shall discard the received packet. The DCE shall 
indicate clearing by transmitting to the DTE a CLEAR INDICATION packet with the cause 
"Local procedure error" and diagnostic No. 81 or No. 82, as appropriate; the DCE shall 
consider the clearing procedure complete and enter state pl. The distant DTE is also 
informed of the clearing by a CLEAR INDICATION packet, with the cause "Remote 
procedure error™ (same diagnostic). 


7.2.5 Fast Select Acceptance 


7.2.5.1 SNA-tO-SNA Connections 


The possible use of the Fast Select Acceptance in SNA environments is a-subject for 
further study. , 


7.2.5.2 SNA-to-non_SNA Connections 


Fast select acceptance is an optional user facility agreed for a period of time. This 
user facility, if subscribed to, authorizes the DCE to transmit to the DTE INCOMING 
CALL packets which request the fast select facility. In the absence of this facility, 
the fave will not transmit to the DTE incoming calls which request the fast select 
facility. 
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7.2.6 ‘"D" Bit Modification 


Use of the 'D" bit Modification facility is not allowed in SNA environments. 


(Text deleted). 


7.3. PROCEDURES FOR OPTIONAL USER FACILITIES ONLY AVAILABLE WITH DATAGRAM SERVICES 


Datagram services are not used in SNA environments. 


(Text deleted). 
7.4 FORMATS FOR OPTIONAL USER FACILITIES 


7.%.1 General 


The Facility field is present only when a DTE is using an optional user facility 
requiring some indication in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, CALL 
CONNECTED, CLEAR REQUEST or CLEAR INDICATION (text deleted) packets. 

The Facility field contains one or more facility elements. The first octet of each 
facility element contains a facility code to indicate the facility or facilities 
requested. 

Note: A facility code must not appear more than once in SNA environments. 

The facility codes are divided into four classes, by making use of bits 8 and 7 of the 
facility field, to specify facility parameters consisting of ‘'1l', "2", '"3', ora 


variable number of octets. The general class coding of the facility code field is 
shown in Table II-1L5. 


Table II-15 — Facility code field class coding 


paolo ets: | SERENE 
CLASS} 8765 4321 Characteristics 

PA [ooxx xxxx| sincle octet 
Te [eaxx xxxx| sovble octet 
Po faaxx xxxx| variable lensth 


For class 'D*® the octet following the facility code indicates the length, in octets, 
of the facility parameter field. The facility parameter field length is binary coded 
and bit 1 is the low order bit of this indicator. Formats for the four classes are 
shown in Table II-16. 
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Tabla: f1=16 = Facilities: Formats 
CLASS A —_ CLASS B 
Bits8 7 6 543 21 Bits8 7 654321 


Octet Octet 
0 X X X X X X 0 


Facility parameter 


field 


CLASS C CLASS D 


Bits 8 7 6 5 4 3 2 1 Bits 8 7 6 5 4&4 3 2 1 
Octet Octet 
0 0 11431 %* X X XK XK X 


Facility Facility parameter 
field length 
parameter 


Facility 
field 


parameter 


field 


The facility code field is binary coded and, without extension, provides for a maximum 
of 64 facility codes for classes "A", "B" and 'C’ and '63' facility codes for class 'D' 
giving a total of '255' facility codes. 


Facility code x'FF* is reserved for extension of the facility code. The octet 
following this octet indicates an extended facility code having the format "At, '"B’, 
'C' or 'D’ as defined above. Repetition of facility code x'FF' is permitted and thus 
additional extensions result. 


The coding of the facility parameter field is dependent on the facility being 
requested. 


A facility code may be assigned to identify a number of specific facilities, each 
having a bit in the parameter field indicating facility requested/facility not 
requested. In this situation, the parameter field is binary encoded with each bit 
position relating to a specific facility. A '0O' indicates that the facility related 
to the particular bit is not requested anda ‘'l' indicates that the facility related to 
the particular bit is requested. Parameter bit positions not assigned to a specific 
facility are set to zero. If none of the facilities represented by the facility code 


1s requested for a virtual call the facility code and its associated parameter field 
need not be present. 


A Facility Marker, consisting of a single octet pair, is used to separate requests for 
X.25 facilities, as defined in this section, from requests for non-X.25 facilities 
that may also be offered by an Administration. The first octet is a facility code and 
is set to zero and the second octet is the facility parameter field. 


The coding of the parameter field will be either all zeros or all ones depending on 
whether the facility requests following the marker refer to facilities offered by the 
calling/source or called/destination network, respectively. For intranetwork virtual 
calls the parameter field should be all zeros. 


Requests for non-X.25 facilities offered by the calling/source and called/destination 
networks may be simultaneously present within the facility field and in such cases two 
Facility Markers will be required with parameter fields coded as described above. 


Within the facility field, requests for X.25 facilities precede all requests for 
non-X.25 facilities and Facility Markers need only be included when requests for 
non-X.25 facilities are present. 
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7.4.2 Coding of Facility Field for Particular Facilities 


7.4.2.1 Coding of Closed User Group Facility 


The coding of the facility code field and the format of the facility parameter field 
for Closed User Group are the same in CALL REQUEST and INCOMING CALL (text deleted) 
packets. 
1. Facility Code Field 
The coding of the facility code field for Closed User Groups is: 
bit: 87654321 
code: 00000011 
2. Facility Parameter Field 
The index to the Closed User Group selected for the virtual call is in the form of 
two decimal digits. Each digit is coded in a semi-~octet in binary coded decimal 
with bit 5 being the low order bit of the first digit and bit 1 being the low order 
bit of the second digit. 


Indexes to the same Closed User Group at different DTE/DCE interfaces may be 
different. 


7.4.2.2 Coding of Bilateral Closed User Group Facility 


The Bilateral Closed User Group facility is not used in SNA environments. 


(Text deleted). 


7.4.2.3 Coding of Reverse Charging Facility 
The coding of the facility code and parameter fields for Reverse Charging is the same 
in CALL REQUEST and INCOMING CALL (text deleted) packets. 
1. Facility Code Field 
The coding of the facility code field for Reverse Charging is: 
bit: 87654321 
code: 00000001 
2. Facility Parameter Field 
The coding of the facility parameter field is: 
bit 1 = '0" for Reverse Charging not requested 
bit 1 = "1" for Reverse Charging requested 
Note: Bits 6, 5, 4, 3, and 2 may be used for other facilities; if not, they are set to 


ane Use of bits 8 and 7 are described in "Coding of Fast Select Facility™ on page 
I-82. : 
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7.4.2.% Cading of RPOA Selection Facility 


The coding of the facility code and parameter fields for RPOA Selection is the same in 
CALL REQUEST and INCOMING CALL (text deleted) packets. 


1. 


2. 


Facility Code Field 

The coding of the facility code field for RPOA Selection is: 
bit: 8 7 6 5 4 321 
code: 01000100 

Facility Parameter Field 


The serameter field contains the Data Network Identification Code for the 
requested RPOA transit network, and is.in the form of 4 decimal digits. 


Each digit is coded ina semi-octet in binary coded decimal with bit 5 of the first 
octet being the low order bit of the first digit, bit 1 of the first octet being 
the low order bit of the second digit, bit 5 of the second octet being the low 
order bit of the third digit, and bit 1 of the second octet being the low order bit 
of the fourth digit. 


7.4.2.5 Coding of the Flow Control Parameter Negotiation Facility 


Aes 


2. 


Coding for Packet Sizes 
The coding of the facility code field and the format of the facility parameter 
field for packet sizes are the same in CALL REQUEST, INCOMING CALL, CALL ACCEPTED 
and CALL CONNECTED packets, where: 
a. Facility Code field 
The coding of the facility code field for packet sizes is: 
bit: 87654321 
code: 01000010 
b. Facility Parameter. Field 
The packet size for the direction of transmission from the called DTE is 
indicated in bits 4, 3, 2, and 1 of the first octet. The packet size for the 
direction of transmission from the calling DTE is indicated in bits 4, 3, 2> 


and 1 of the second octet. Bits 5, 6, 7 and 8 of each octet must be x'd". 


The four bits indicating each packet size are binary coded and express the 
logarithm base '2' of the number of octets of the maximum packet size. 


Networks may offer values from '4"* to '10*, corresponding to packet sizes of 


16, 32, 64, 128, 256, 512, or 1024, or a subset of these values. All 
Administrations provide a packet size of '128’. 


Coding for Window Size 
The coding of the facility code field and the format of the facility parameter 
field for window .sizes are the same in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, 
and CALL CONNECTED packets, where: 
a. Facility Code Field 
The coding of the facility code field for window size is: 
bit: 87654321 
code: 01000011 
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b. Facility Parameter Field 


The window size for the direction of transmission from the called DTE is 
indicated in bits 7 to 1 of the first octet. The window size for the direction 
of transmission from the calling DTE is indicated in bits 7 to 1 of the second 
octet. Bit 8 of each octet must be '"0*. 


The bits indicating each window size are binary coded and express the size of 
the window. A value of b*'0000000" is not allowed. 


Window sizes of °8' to '127' are only valid if extended sequence numbering is 
used (see "Extended Packet Sequence Numbering" on page II~-69). The ranges of 
values allowed by a network for calls with normal (modulo '8') packet sequence 


numbering and extended (modulo '128') packet sequence numbering are network 
dependent. All Administrations provide a Window size of two (2). 


7.4.2.6 Coding of Throughput Class Negotiation Facility 


The coding of the facility code field and the format of the facility parameter field 
for Throughput Class Negotiation are the same in CALL REQUEST, INCOMING CALL, CALL 
ACCEPTED AND CALL CONNECTED packets. 
1. Facility Code Field 
the coding of the facility code field for Throughput Class Negotiation is: 
bit: 876564321 
code: 00000041 0 
2. Facility Parameter Field 
The throughput class for transmission from the calling DTE is indicated in bits 4, 
3s : and 1. The throughput class for transmission from the called DTE is indicated 
an its 8, 7 > 6 and 5. 


The four bits indicating each throughput class are binary coded and correspond to 
the throughput classes indicated in Table II-17. 


Table II-17 — Throughput Class Codings 
bits 4 3 Throughput Class 


or 
bits 8 7 (bit/s) 
Reserved 
Reserved 
Reserved 


Reserved 
Reserved 
Reserved 


HM HMODR HOOrRKOOHHOO | aw 
MOR OR OK OR OF OrHFOrFO | Ul 


0 
0 
0 
0 
0 
0 
0 
0 
1 
1 
1 
1 
1 
1 
1 
1 


Mr ree OOO OF KR RH OOS Oo 
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7.4.2.7 Coding of Fast Select Facility 


1. SNA-to-SNA Connections 


The possible use of the Fast Select facility on SNA-to-SNA CONNECTIONS is a 
subject for further study. 


2. SNA-to-non_SNA Connections 
The coding of the facility code and parameter field for Fast Select is the same in 
CALL REQUEST and INCOMING CALL packets, where: 
a. Facility code field 
The coding of the facility code field for fast select is: 
bit: 87654321 
code: 00000001 
b. Facility parameter field 
The coding of the facility parameter field is: 
bit 8 = 0 and bit 7 = 0 or 1 for fast select not requested 


bit 8 = 1 and bit 7 = 0 for fast select requested with no 
restriction on response 


bit 8 1 and bit 7 = 1 for fast select requested with 


restriction on response 


Note: Bits 6, 5, 4, 3 and 2 may be used for other facilities; if not, they are set to 
0. Use of bit 1 is described in "Coding of Reverse Charging Facility” on page II-79. 


7.4.2.8 Coding of Datagram Non-delivery Indication Facility 


The Datagram Non-delivery Indication facility is not used in SNA environments. 


(Text deleted). 


7.4.2.9 Coding of Datagram Delivery Confirmation Facility 


The Datagram Delivery Confirmation facility is not used in SNA environments. 


(Text deleted). 
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8.0 LOGICAL LINK CONTROL (LLC) ON SNA-TO-SNA CONNECTIONS 


In SNA-to-SNA environments, virtual circuits are viewed, by SNA Physical Unit 
(SNA.PU), SNA Path Control (SNA.PC) and the higher layers as communication lines 
(physical media) with the ability to support multiple sessions. Permanent virtual 
circuits (PVC)s appear to the higher layers of SNA as dedicated (leased) lines, while 
virtual calls (VCs), also referred to as switched virtual circuits (SVCs), appear as 
switched lines. 


In this environment a logical link control function is required to enhance the quality 
of service provided by the underlying service and to accommodate SNA adjacent node 
physical services equivalent to such SDLC functions as: 


identification information exchange (XID); 
operational mode selection (SNRM, SABM, etc.); 
link test (TEST); and, 

link disconnection (DISC). 


Differences between the error detection and recovery characteristics for adjacent SNA 
nodes in the Public Switched Telephone Network and the Packet-Switched Data Network 
environments are depicted in Figure 19 on page II-84 


Three types of logical link control are defined: 


1. Qualified Logical Link Control (QLLC) which employs the Qualified Data Indicator 
*Q@-bit® in X.25 DATA packets to identify unnumbered and supervisory Receive_Ready 
QLLC commands and responses; and, designed for use with PSDN virtual circuit 
Goce: that exhibit quality of service characteristics that are acceptable to 

e user. 


2. Physical Services Header (PSH) LLC which is employed in certain early IBM SNA X.25 
DTE implementations and described briefly in appendix H; and, 


3. Enhanced Logical Link Control CELLC) which employs extended formats and the 
procedures described in appendix K. ELLC provides error detection and optional 
retransmission recovery capabilities, designed to enhance the quality of service — 
exhibited by underlying virtual circuits. While ELLC may be selected by the user 
ona virtual circuit basis, the optional retransmission capability applies to the 
Se ertors and may be controlled by the value of LLC parameter LN2 (see 

~K.6.5.4). 


QLLC and the ELLC procedures described in appendix K are both considered base 
architecture to be supported by all IBM SNA X.25 DTEs except the: 


ks nee Network Interface Adapter (NIA) which supports only the PSH protocol; 
and >» 


2. IBM-5251-M12 which does not support the ELLC protocol. 


Consequently, IBM SNA X.25 DTEs that remotely attach to the IBM 5973 NIA must be 
capable of using PSH_LLC, as well as QLLC and ELLC. 


The LLC protocol used for operation on PVCs is established by bilateral agreement 
betkz:en' communicating DTEs, while a Protocol_Identifier (PI) carried in the first 
octet of the Call User Data (CUD) field in X.25 CALL_REQUEST packets is used to 
negotiate the LLC protocol applicable for operation on VCs. CALL_REQUEST packets for 
virtual calls desiring to use ELLC procedures have the PI set to x'C6'. DTEs that do 
not yet support ELLC, and IBM 5973s that support only PSH_LLC, reject such calls by 
sending a CLEAR_REQUEST packet with the DTE Generated Cause (x'00') and the Diagnostic 
Code #12, ‘Invalid LLC Type’. Calling DTEs may then reinitiate the call by sending a 
CALL_REQUEST packet with PI set to x'C3' requesting a connection for QLLC operation, 
or with PI set to x'C2* to request a connection for PSH_LLC operation. 


PSH_LLC formats and procedures for their use are outlined briefly in appendix H, while 
the formats, protocols and procedures for ELLC are described in appendix K. 
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1 —- SDLC Error Detection and Retransmission Recovery or Reporting 
2 — LAPB. Error Detection and Retransmission Recovery or Reporting 
3 - Virtual Circuit Error Detection and Reporting 

4 —- Q@LLC or ELLC Error Detection and Recovery or Reporting 

5 — SNA Session-Level Error Recovery or Reporting 


Logical Link Control 
X.25 Packet Layer | 
X.25 Link Layer © | 


and Recovery: in Different Network Service 


2 Figure 28 on page II-85 shows the correlation between ELLC/QLLC functions and 


2 equivalent SDLC functions. 
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Note: PSH_LLC is primary/secondary only. 
ELLC is peer-to-peer only. 


Figure 20. COMMAND/RESPONSE REPERTOIRE: ELLC versus QLLC versus SDLC and 
PSH_LLC 


Peer-to-Peer QLLC, where either link station may initiate actions (i.e., transmit 
commands), utilizes HDLC asynchronous balanced mode (ABM) functions. 


Primary/Secondary QLLC, where only primary link stations initiate actions, utilizes 
HDLC normal response mode (NRM) functions while secondary link stations respond to NRM 
functions initiated by primary link stations, and may asynchronously transfer the QRD 
response. 


Procedures for use of the QLLC protocols by Balanced, Primary, and Secondary link 
stations are described in this section. 


8.1 QUALIFIED LOGICAL LINK CONTROL ( QLLC ) 


QLLC is designed to facilitate adjacent SNA node physical services where such nodes 
are connected through X.25-based packet-switched data network(s). It uses X.25 DATA 
packets with the Qualifier Bit set equal to '"1* (€'Q=1', hereafter referred to as 
"Q-packets') to transfer HDLC-like commands and responses and is to be provided by all 
ahr eas DTEs, except the 5973 NIA and the 5251-M12, as a base Logical Link Control 
protocol. 


QLLC uses HDLC unnumbered commands and the Receive_Ready supervisory command and 
response, identical to their SDLC counterparts, carried as user data in Q-packets. 
Q@LLC commands and responses are initiated by the same higher level events that 
initiate their SDLC counterparts and timeout processing, as itn SDLC, should be 
considered for all QLLC commands. 


8.1.1 Terminology 


Q@LLC link station configurations include balanced (Cor peer-to-peer) station 
configurations, primary station configurations and secondary station configurations 
that function as described in “Terminology,” as well as ‘combined stations’ that. 
exhibit balanced station characteristics until role negotiation is completed via an 
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exchange of identification information when they assume the role and functions of 


either primary or secondary link stations depending on the outcome of the role 
negotiation process. | 


Q@LLC is used by two adjacent link stations to exchange elementary units of information 
over a link connection in either of three environments; peer-to-peer, 
primary/secondary or indirectly coupled; as depicted in Figure 21. One link station 
acts as either a PEER or PRIMARY link station, associated with a DTE attached to a PSDN 
via an X.25 DTE/DCE interface to communicate with another link station associated with 
a DTE attached to the same or another PSDN, which acts as either a PEER or SECONDARY. 


In indirectly coupled configurations, a packet assembly/disassembly (PAD) function, 
provided either by the PSDN or as a standalone interface adapter, acts as the ‘REMOTE 
DTE’ and correlates actions that take place across the link connection to actions that 
take place across the access link connecting the interface adapter and the secondary 
link station. In this environment the secondary link station is referred to as the . 
"Related Secondary Station CRSS). 
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LOCAL/REMOTE DTE | REMOTE/LOCAL DTE 
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Figure 21. Qualified Logical Link Control: Environments 


8.1.2 Objectives 


The objective of QLLC is to provide adjacent node physical services equivalent to 
those used by SDLC in SNA. It must help to keep the 'LOCAL DTE* informed of the 
situation In the "REMOTE DTE’ and/or the "Related Secondary Station’. 
Segmentation/concatenation of data packets is performed by the packet level procedures 


at both ends of the link connection by means of the More Data Mark 'M-bit' procedures 
defined in §-4.3.4. 
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8.1.3 QLLC Elements 


The basic elements of information exchanged are called Logical Link Units (LLUs). Two 
types of LLUs are defined: 


QiLUS - composed of commands or responses together with their uses and the resultant 
actions performed by link stations at both the local and remote DTEs are described in 
§-8.2 (Elements of Procedure). QLLUs are conveyed between adjacent link stations in 
Q-packets formatted as shown in Figure 22 on page II-90. 


DLLUsS - appearing as SNA Basic Transmission Units (BTUS), carried in the user data 
field of X.25 DATA packets with the 'Q' bit set to zero and the 'M® bit set to either 
"@* or "1", are used to convey user data between adjacent link stations in local and 
remote DIEs. 


The X.25 Delivery Confirmation "D-bit' procedures are not used. 


8.1.4 Link Connection States 


Link connections may be perceived by link stations as being in any one of six basic 
states at any particular instant in time. 


8.1.4.1 INOPERATIVE 


A link connection is perceived by the link stations to be in the INOPERATIVE state when 
the supporting virtual circuit ts inoperative. In this’ state Peer, Primary and 
Secondary link stations neither transmit nor receive QLLUs or DLLUs. 


8.2.4.2 LINK_CLOSED 


The LINK_CLOSED state is comparable to the LAPB link layer disconnected phase. Peer 
and Primary link stations may initiate an exchange of identification tnformation 
(QXID), or a link test (QTEST) procedure over link connections perceived to be itn this 
state. Some may also initiate the link set-up procedure (transmit a QSM command). 
Secondary link stations accept and respond to QXID and QTEST commands received over 
link connections perceived to be in this state. Some may also accept and respond to 
QSM commands. Some Peer and Secondary link stations respond QDM to @SM commands 
recetved across link stations in this state until after a successful exchange of 
identification information has been completed. 


8.1.4.3 LINK _OPENING 


The LINK_OPENING state is comparable to the link layer set-up phase. Peer and Primary 
link stations expect a response (QUA or QDM) to a set mode (QSM) command previously 
transmitted across link connections perceived to be in this state. Peer link stations 
also respond (QUA) to set mode (QSM) commands received across link connections 
perceived to be in this state. Secondary link stations accept and respond (QUA) to set 
mode (QSM) commands received across link connections perceived to be in this state. 


8.1.4.4 LINK_RECOVERY 


The LINK_RECOVERY state is comparable to the link layer frame rejection phase. Peer 
and Secondary link stations retransmit the QFRMR response on link connections 
perceived to be in this state at each respond opportunity until recovery is effected 
by the ‘adjacent link station, or until internal recovery is initiated locally. 
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8.1.4.5 LINK CLOSING 


This state is comparable to the link layer disconnection phase. Peer, Primary and 
Secondary link stations await satisfactory termination of link connections in this 
state. 


8.1.4.6 LINK_OPENED 


The LINK_OPENED state is comparable to the link layer information transfer phase. 
Q@LLUs and DLLUs may be transmitted and received by both link stations across: link 
connections perceived to be in this state. 


8.1.5 Link Connection Predicate Conditions 


Predicate conditions applicable to the various states of the link connection include: 


8.1.5.1 Contact Termination Pending - CTp 


Represents the Secondary link station condition in which receipt of a Receive Ready 
CQRR) command QLLU from the Primary link station is required to terminate the 
SNA_CONTACT phase on link connections perceived to be in the LINK_OPENING state. 


8.1.5.2 Other Predicate Conditions - ELSE 


Signifies all predicate conditions not otherwise shown for a particular stimulus. 


8.1.5.3 Incoming/Outgoing TEST Response Pending - IOTRp 


Transmission and receipt of TEST response QLLUs containing test patterns to and from 
the link station in the adjacent node are pending. 


8.1.5.4 Incoming/Outeoing XID Response Pending - IOXRp 


Transmission and receipt of XID response QLLUs containing link station identification 
information to and from the link station in both adjacent nodes are pending. 


8.1.5.5 Incoming TEST Response Pending - ITRp 


Receipt of a TEST response QLLU containing the test pattern from the link station in 
the adjyacent node 1s pending. 


8.1.5.6 XID/TEST Response Pending - IXOTRp 


Receipt of an XID response QLLU containing link station identification information 
from and transmission of a TEST response QLLU containing the test pattern to the link 
station in the adjacent node are both pending. 
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8.1.5.7 Incoming XID Response Pending - IXRp 


Receipt of an XID response QLLU containing link station identification information 
from the link station in the adjacent node is pending. 


8.1.5.8 No Predicate Condition - NUL 


Signifies that no transient predicate condition exists to alter the action required of 
the link station. 


8.1.5.9 TEST/XID Response Pending - OTIXRp 


Receipt of an XID response QLLU containing link station identification information 
from and transmission of a TEST response QLLU containing the test pattern to the link 
station in the adjacent node are both pending. 


8.1.5.10 Outgoing TEST Response Pending - OTRp 


Transmission of a TEST response QLLU containing the test pattern to the link station 
tn the adjacent node is pending. 


8.1.5.11 Outgoing XID Response Pending - OXRp 


Transmission of an XID response QLLU containing link station identification 
information to the link station in the adjacent node is pending... 


8.1.5.12 Remote RESTART Pending - RRp 


A RESTART of the X.25 DTE/DCE Interface providing Called (remote) DTE access to the 
network is pending. 


8.1.5.13 SET_MODE Pending - SMp 


Peer and Primary link stations, having completed a successful exchange of 
identification information across a link connection perceived to be in the LINK_CLOSED 
state, may transmit a @SM command QLLU when authorized by the higher levels of SNA. 
Peer and Secondary link stations accept and respond to QSM command QLLUS received on 
link connections perceived to be in this state. | 


8.2 QLLC ELEMENTS OF PROCEDURE 


8.2.1 Q-Packet Formats 


a used by QLLC conform to one of the formats depicted in Figure 22 on page 
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| Bits | | 
8 7 6 5 4 3 2 1 
Octet | . 
1 ai i one: ener (GFI) Logical channel group number 
1 
2 Logical channel number 
4 QLLC Address Field 
(Coded x'FF' for Commands or # x'FF for Responses) . 
5 | . QLLC Control Field — | 
6 
® QXID/QTEST/QFRMR Information Field (Optional) 
n 
C(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 
Octet 
i. * ii ae pean velen (GFI) Logical channel group number 
0 
2 Logical channel number 
a 2 
‘ LT ERS Hee 
5 QLLC Address Field 
| (Coded x'FF* for Commands or # x'FF* for Responses) 
6 QLLC Control Field 
7 
@ 
n 


QXID/QTEST/QFRMR Information Field (Optional) | 


CModulo 128) 
M = More Data Mark 


Figure 22. QUALIFIED_DATA: Packet Formats 


8.2.1.1 QLLC Address Field 


The address field consists of one octet. The contents of the address field is set to 
x"FF" in *Q-packets' containing commands and to any value other than x'FF’' in 
"Q-packets® containing responses. 


8.2.1.2 QULLC Control Field 


The control field consists of one octet. The control field contains the 
command/response transmitted by the peer, primary or secondary link station as 
depicted in Figure 23 on page II-91. | ee | 
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8.2.1.3 QLLC Information Field 


The information field consists of a variable number of octets and is used to carry 
QXID, QTEST or QFRMR data. 7 


8.2.2 QLLC Commands and Responses 


Figure 23 shows the code points for the HDLC eGmmands7 responses used by peer, primary 
and secondary QLLC link stations. ny | | 


QLLC j I-Field Primary Secondary Peer-to-Peer 
Function Allowed Command Response 


Note: The Address field as defined for SDLC is octet ' . 


Figure 23. DTE and DCE DATA Packet: User Data Field Format 


8.2.2.1 @ Set_Mode - QSM 


The Set_Mode command QLLU is transmitted by peer and primary link stations to place 
the link connection, as perceived by the link station in the adjacent node, in the 
LINK_OPENED state. No information field is permitted with the QSM command. 


Upon receipt of the Set_Mode command QLLU peer and secondary QLLC link stations, 
authorized by the higher layers of SNA, transfer a UA response QLLU confirming 
acceptance of the Q@SM command and place the link connection in the LINK_OPENED state. 
Peer.and primary QLLC link stations, having transferred a Set_Mode command QLLU place 
the Link connection in the LINK_OPENED state upon receipt of the UA response QLLU from 
the peer or secondary Q@LLC link station in the adjacent node. 


8.2.2.2 Q Disconnect - QDISC 


The Disconnect command QLLU is transferred by peer and primary QLLC link stations to 
place the link connection, as perceived by the peer or secondary QLLC link station in 
the adjacent node, in the LINK_CLOSED state. No information field is permitted with 
the Q@DISC command. 


Upon receipt of the DISC command QLLU peer and secondary QLLC link stations, on link 
connections perceived to be in other than the LINK_CLOSED state, transfer a UA 
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response QLLU confirming acceptance of the QDISC command and place the link connection 
in the LINK_CLOSED state. Link connections perceived to be in the LINK_CLOSING state, 
by peer and primary Q@LLC link stations, are placed in the LINK_CLOSED state upon 
receipt of a UA response QLLU by that QLLC link station. 


8.2.2.3 Q_Exchange_Identification - Q@xID 


The Exchange_Identification command QLLU may be issued by peer and primary @Q@LLC link 
stations at any time to solicit identification information from the peer or secondary 
communicating link station in the adjacent node. The information field of the QXID 
command/response contains the transmitting link station's identification information. 


Upon receipt of an XID command QLLU, peer and secondary QLLC link stations transfer 
the corresponding XID response QLLU as soon as the identification information is 
available. 


8.2.2.4 Q_Test_Link - QTEST 


The TEST command QLLU may be issued by peer and primary QLLC link stations at any time 
to solicit a TEST response QLLU from the peer or secondary QLLC link station in the 
a aaa The information field of the TEST command/response contains the test 
pattern data. 


Upon receipt of a TEST command QLLU, peer and secondary QLLC link stations transfer 
the corresponding TEST response QLLU with the information field containing the test 
pattern data received in the QTEST command. 


8.2.2.5 Q Request_Disconnect - QRD 


The Request_Disconnect response QLLU may be used by secondary QLLC link stations to 
request the primary QLLC link station to place the link connection as perceived by the 
secondary QLLC link station in the LINK_CLOSED state Ci.e., initiate the link 
disconnection procedure by transferring a QDISC command across the link connection). 
As a result of receiving a DISCONTACT or similar request from a higher SNA level, 
secondary QLLC link stations may transfer a QRD response, when. no other responses 
(such as acknowledgments for received DLLUs or responses to received Unnumbered 
commands) are pending and start Query Timer, Tq. Should Query Timer Tq expire prior to 
receipt of the requested QDISC command, the Q@RD response may be retransmitted up to Nq 
times. DLLUs received by the secondary QLLC link station after transmission of the 
Q@RD response and prior to receipt of the requested QDISC command are accepted and 
responded to in the normal way. No information field is permitted with the QRD 
response. | 


Upon receipt of a QRD response the primary QLLC link station will transfer a QDISC 
command when authorized by a higher levels of SNA. 


8.2.2.6 Q_Unnumbered_Acknonledgment - QUA 


The Unnumbered_Acknowledgment response QLLU is transferred by peer and secondary QLLC 
link stations in response to Q@SM or QDISC commands. No information field is permitted 
with the QUA response. 


Upon receipt of the QUA response across a link connection perceived by a peer or 
primary QLLC link station to be in the LINK_OPENING state the receiving peer or 
primary QLLC link station places that link connection in the LINK_OPENED state. Upon 
receipt of the QUA response across a link connection. perceived by a peer or primary 
Q@LLC link station to be in the LINK_CLOSING state the receiving peer or primary QLLC 
link station places that link connection in the LINK_CLOSED state. 


Logical Link Control (LLC) on SNA-to-SNA Connections | II-92 


2 
2 
2 


NMNM MM MD RMP MDM MMMM MMMM NPP MPM MP PMD PPP NN 


SNA/X.25 DTE/DCE Interface 
8.2.2.7 Q Receive Ready - QRR 


The Receive _Ready command @QLLU may be transferred by peer and primary QLLC link 
stations to indicate that the link connection is in the LINK_OPENED state and the QLLC 
link stations are prepared to accept and respond to DLLUs. 


8.2.2.8 Q Disconnected Mode - QDM 


The Disconnected_Mode response QLLU may be transferred by peer and secondary QLLC link 
stations in response to QSM or QDISC commands. No information field is permitted with 
the QDM response. 


Receipt of a Q@DM response informs the receiving peer or primary QLLC link station that 
the link connection, as perceived by the communicating QLLC link station in the 
adjacent node, is in the LINK_CLOSED state. 


8.2.2.9 Q Frame_Reject - QFRMR 


The Frame_Reject response QLLU may be used by peer and secondary QLLC link stations to 
inform the communicating QLLC link station in the adjacent node of an error condition 
that is considered to be unrecoverable, at the LLC level, by retransmission of the 
identical LLU. 


Upon receipt of a QFRMR response, peer and primary @QLLC link stations cause a clearing 
of the VC or a resetting of the PVC supporting the link connection and inform a higher 
SNA level protocol of the failure. The format of the information field of the 
Frame_Reject response QLLU 1s depicted itn Figure 24. 


I-field bits 
2 7 8 


Rejected LPDU 
Control Field 


® Rejected LPDU control field is the control field of the received 
LPDU that caused the frame reject. 


® Vs is reserved and set to b'000". 
e Vr is reserved and set equal to b‘'000". 
® 'W=1" indicates that the control field received and returned in bits 


1 through 8 was considered invalid or not implemented. 

° "X=1" indicates that the control field received and returned in bits 
1 through 8 was considered invalid because the LPDU contained an 
information field which is not permitted or is an S or U-frame with 
incorrect length. "W=1" ain required in conjunction with this bit. 

e "Y=1" indicates that the information field received exceeded the 
maximum established capacity of the link station reporting the rejection 
condition. 

e gr 1S reserved and set equal to b'0'. 

Note: Bit 13 is set to: 


Ti’ if the LPDU rejected was a response; or, 
"O’ If the LPDU rejected was a command. 
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Figure 24. QFRMR: Information Field Format 


8.2.3 Call User Data ( CUD ) Field Format 


The format of the CUD field for CALL_REQUEST and INCOMING CALL packets on SNA-to-SNA 
connections is illustrated in Figure 25. 
Bits S « 7 6 5 4 3 2 1 


Octet 
0 


COptional) 
1 Field Format Identifier (FFI) 


ELLC Call Control Indicator 


2 x x x x x  & x I/R 
z | Format Specific Field | 


'O’ for initial connection. 
"1" for connection recovery. 
Note: Bits indicated as 'x' are reserved and should be set to 0's 


Figure 25. CALL_USER_DATA Field Format: CALL_REQUEST and INCOMING_CALL Packets 


8.2.3.1 Field_Format_Identifier ( FFI ) 


The FFI is optional and when present, defines the format of the remainder of the CUD 
field. IBM SNA X.25 DTE implementations that use FFIs must make such use optional. 
IBM SNA X.25 DTEs that do not support FFIs must accept and ignore CUD fields of up to 
15 octets in addition to the Protocol Identifier. Figure 26 on page II-95 illustrates 
the format of the CUD field for the only optional FFI currently defined, b'xxxxxxx1!' 
where the bits denoted by 'x's, bits 8 thru 2, are reserved and set to zeroes. 
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Bits 8 7 6 5 4 3 2 1 
Octet 
0 


1 Field_Format_Identi fier 
x x x x 

2 ELLC_Call_Control_Indicator 

x x x 
3 Reserved 

0 
4 

a | Connection_Identi fier | 

1 


"0" for initial connection. 
"1" for connection recovery. 


Note: Bits indicated as 'x' are reserved and should be set to 0's 


Figure 26. CALL_USER_DATA Field Format: CALL_REQUEST and INCOMING CALL Packets 
with Connection_Identifiers. 


8.2.3.2 ELLC_ Call_Control_Indicator - ( ELLC_CCI ) 


The ELLC_CCI Cbit 1 of octet 2) is used to distinguish between initial connection 
requests and connection recovery requests, while the remaining bits, denoted by ‘x's 
in Figure 25 on page II-94 and Figure 26, are reserved and set to zero ('0's). 


8.2.3.3 Connection_Identifier - ( cr ) 


The CI is eight octets in length and permits IBM SNA X.25 DTEs to accept or reject 
oe calls based on its content. The following rules apply to the use of the 
optional CI: 


1. Some IBM SNA X.25 DTEs may not support the Connection_Identifier. 


2. For IBM SNA X.25 DTEs that do support a Connection_Identifier, its use is optional 
ona per call basis at the discretion of the user. 


3. IBM SNA X.25 DTEs that support Connection_Identifiers may reject incoming calls by 
transferring a CLEAR_REQUEST with the Diagnostic Code #236 (Connection Identifier 
Mismatch) when the Connection_Identifier does not compare with one that is 
expected. | 


8.3 DESCRIPTION OF THE QLLC PROCEDURES 


Charts in "Balanced Link Stations” on page II-104, "Primary Link Stations” on page 
II-116 and "Secondary Link Stations" on page II-123 specify actions taken by balanced 
(PEER), primary and secondary QLLC link stations, respectively, as a result of events 
that occur, and LLC command and response LLUs received on link connection perceived to 
be in the various states. 
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8.3.1 Link Set-Up 


8.3.1.1 Initiation - Al 


Peer and primary QLLC link stations authorized by the higher levels of SNA, initiate 
link setup by transferring a Set_Mode command QLLU placing the link connection in the 
LINK_OPENING state. Some may also start LLC Query Timer (Tq). 


8.3.1.2 Acknowledgment - A2 


Upon receipt of a Set _Mode command QLLU, peer and secondary QLLC link stations 
authorized by the higher levels of SNA to enter the LINK_OPENED state transfer the 
corresponding UA response QLLU. Secondary QLLC link stations then place the link 
connection in the LINK_OPENED state. 


Alternatively, some secondary QLLC link stations may set the link connection predicate 
condition to contact termination pending (CTp) and await receipt of a Receive _Ready 
CRR) command QLLU before placing the link connection in the LINK_OPENED state. Peer 
QLLC link stations maintain the link connection in the LINK_OPENING state until a UA 
response QLLU is received from the QLLC link station in the adjacent node. 


8.3.1.3 Initiation_Retry - A3 


Should Query Timer (Tq) expire prior to receipt of the UA response QLLU or a DM 
response QLLU to the transmitted Set_Mode command or a CLEAR/RESET, indicating that 
the peer or secondary QLLC link station in the adjacent node is not operational, peer 


and Pe oe link stations may retransmit the Set_Mode Eoureane Q@LLU and restart Query 
Timer (Tq 


8.3.1.4 Failure - A4 


After Nq retransmissions of the Set_Mode command QLLU, peer and primary QLLC link 
stations place the link connection in the INOPERATIVE state and report the condition 
to the higher levels of SNA. 


8.3.1.5 Waiting - A5 


Peer and primary QLLC link stations, that do not implement Query Timer, Taq, may wait 
for a UA response QLLU to the transmitted Set _Mode command, or a packet level reset, 
indicating remote DTE operational, on the virtual circuit supporting the link 
connection before taking any further action. 


8.3.1.6 Completion - A6 


Upon receipt of the UA response QLLU to a transmitted Set_Mode command QLLU, peer and 
primary 18 Be link stations stop Query Timer, Tq, if it ts running, place the link 
connection in the LINK_OPENED state and report the status of the link connection to 
the higher levels of SNA. Some peer and primary QLLC link stations may also transmit a 
link Receive_Ready (RR) command QLLU. 
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8.3.1.7 Alternative - A7 


Alternatively, peer and primary QLLC link stations may transfer a Set_Mode command 
QLLU following receipt of a packet level RESET, indicating remote DTE operational, on 
the virtual circuit supporting the link connection. Some may also start Query Timer, 
Tq. 


8.3.1.8 Rejection - A& 


Peer and secondary Q@LLC link stations not authorized, by the higher levels of SNA, to 
set-up the link respond to received Set_Mode command QLLUs by transferring a DM 
response QLLU and maintain the link connection in the LINK_CLOSED state. 


8.3.2 User Data Transfer 


8.3.2.1 Data_Transfer - Bl 


Peer, primary and secondary QLLC link stations on link connections perceived to be in 
the LINK_OPENED state cooperate in the exchange of X.25 DATA packets with 'Q=0!' in 
' accordance with the procedures described in §-4.3. 


8.3.2.2 Resetting - B2 


QLLC link stations receiving a Set_Mode command QLLU or a DM response QLLU on a link 
connection perceived to be in the LINK_OPENED state cause a clearing of the VC or a 
resetting of the PVC supporting the link connection and report the status and reason 
for the change of status in the link connection to the higher levels of SNA. 


8.3.3 Link Disconnection 


8.3.3.1 Primary_Initiation - Cl 


During the LINK_OPENED state Cinformation transfer phase), peer and primary QLLC link 
stations indicate link disconnection, as dictated by the higher levels of SNA, by 
transferring a Disconnect command QLLU across the link connection. Some may also 
start Query Timer, Tq. 


8.3.3.2 Secondary _Initiation - c2 


Secondary QLLC link stations indicate link disconnection, as dictated by the higher 
levels of SNA, by transferring a Request_Disconnect response QLLU, across the link 
connection. Some may also start QLLC Query Timer, Tq. 


8.3.3.3 Acknonledgment - C3 


Upon receipt of a DISC command QLLU, receiving peer and secondary Q@LLC link stations 
return a UA response @QLLU, place the link connection in the LINK_CLOSED state and 
report the status of the link connection to the higher levels of SNA. 
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| 8.3.3.4 Primary_Response - c4é 


Upon receipt of an RD response QLLU, primary QLLC link stations inform the higher 


levels of SNA and transfer a DISC command QLLU across the link connection. Some may 
also start Query Timer, Tq. 


8.3.3.5 Collision - cS 


In the event of a collision of unlike QLLC commands, peer QLLC link stations transfer a 
DM response QLLU at the earliest opportunity, placing the link connection in the 


aie CLOSED state and report the status of the link connection to the higher levels oF 


8.3.4 Link Disconnected Phase 


8.3.4.1 Reporting - Dl 


Peer and secondary QLLC link stations, having received a DISC command QLLU and 
returned a UA response QLLU; and, peer and primary QLLC link stations having received 
a QUA response to a transmitted DISC command QLLU, place the link connection in the 
Syaee ee state and report the status of the link connection to the higher levels of | 


8.3.4.2 Activation - D2 


Peer and primary QLLC link stations on link connections perceived to be in the 
LINK_CLOSED state may initiate the link set-up procedure as described in §-8.3.1 when 
authorized by the higher levels of SNA. 


8.3.%.3 Connecting - D3 


Peer and secondary QLLC link stations on link connections in the LINK_CLOSED state 
that are authorized by the higher levels of SNA react to the receipt of Set_Mode 
command QLLUs as described in §-8.3.1. 


8.3.4.4 Response - D4 


Peer and secondary QLLC link stations on link connections in the LINK_CLOSED state 
transfer a DM response QLLU upon receipt of DISC command QLLUs. 


. 8.3.5 Link Identification Exchange 


8.3.5.1 Initiate_ID_Exchange - El 


Peer and primary QLLC Link stations may initiate the exchange of link identification 


eens vere in certain states, by transferring an XID command QLLU and starting Query 
Imer, Tq. | 
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8.3.5.2 Complete_ID_Exchansge - E2 


Upon receipt of an XID command QLLU, peer and secondary QLLC link stations transfer an 
XID response QLLU when authorized by the higher levels of SNA. 


8.3.6 Link Test 


8.3.6.1 Initiate_Link_Test - Fl 


Peer and primary QLLC link stations may initiate the link test procedure, in certain 
states, by transferring a TEST command QLLU and starting Query Timer, Tq. 


8.3.6.2 Complete_Link_Test - F2 


Upon receipt of a TEST command QLLU, peer and secondary QLLC link stations transfer a 
TEST response QLLU as soon as authorized by the higher levels of SNA 


8.3.7 External Effects on Logical Link Control Procedures 


Certain states and actions are dictated by SNA layers above or below QLLC and are as 
described as follows. 


8.3.7.1 L3_Ready_Signal ~- Gl 


Q@LLC link stations become operational when the Packet Layer (level 3) interface 
signals the READY state. 


8.3.7.2 Set-Up_Link - G2 


Q@2iC link stations perform the link setup only when authorized by the higher levels of 
SMA. 


8.3.7.3 Disconnect_Link - G3 


QLLC link stations initiate the link disconnection procedure when authorized by the 
higher levels of SNA. 


8.3.7.4 L3_Inoperative_Signal - G4 


QLLC link stations become inoperative and inform the higher levels of SNA vihen the | 
Packet Layer (level 3) interface signals the inoperative state. . 


8.3.7.5 XID_Function_Request - G5 - Obsolete 


QLLC link stations initiate an exchange of link station identification information at 
the LLC level only at the request of the higher levels of SNA. 
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8.3.7.6 TESTS FUner Ten Reaves’ - G6- Obsolete 


QLLC link stations initiate a procedure o test the link when authorized Be the higher 
levels of SNA. 


8.3.7.7 Exchange_Identification -~ G7 


QLLC link stations transfer link station identification information command ‘or | 
response QLLUs as appropriate when authorized by the higher levels of SNA. | 


8.3.7.8 TEST_Link Connection - G8 


QLLC link stations transfer link test command or response QLLUs as appropriate when 
authorized by the higher levels of SNA. 


8.3.7.9 DATA_Transfer - 69 


QLLC link stations cooperate with the higher levels of SNA.to exchange BTUs over link 
connections perceived to be in the LINK_OPENED state. 


8.4 STATE/ACTION CHART DESCRIPTION 


Operation of the QLLC protocol for balanced, primary and secondary link stations is 
formalized by the charts contained in "State/Action Charts" on page II-104. Action(s) 
taken by link station(€s) as a result of particular stimuli are shown at the 
intersection of the various link connection states and the stimulus. LLC stimuli 
include the events and command and response LLUs defined in §-8.4.1. QLLC link 
connection states include the predicate conditions defined in §-8.1.5 which are 
indicated under the heading 'P:' Cif any) tn the state/action charts. , 


Information contained at these intersections specify the action(s) taken, Cdenoted by 
two uppercase letters 'LL' or by a single uppercase letter concatenated with a number 
*"L#'), the LLUCs) to be transferred Cif any), enclosed in brackets with any required 
parameters [LLU, parms] and the new state of the link connection to be entered Cif 
any). 


The LLUCs) to be transferred, [CLLUJ, may be any of the LLC command or response LLUs 
depicted in Figure 23 on page II-91. In the event the LLU to be transferred causes a 
packet level clearing or resetting of the associated virtual circuit, an appropriate 
diagnostic code must be included (see Appendix F for DTE Generated Diagnostic codes 
used on SNA-to-SNA connections). When no LLU to be transferred, [LLUJ, is indicated, 
nothing is transferred across the link connection. 


Applicable QLLC link connection state transitions are specified under the heading New 
State when the link connection is to be placed in a new state following the specified 
action and/or transfer of the LLU specified by [LLU]. Link connections remain in the 
current state when no new state to be entered is specified. 


Alternative procedures, denoted by lower case letters '1l' or ‘or' under the CALT) 
heading, are specified where appropriate. 


References to clarifying notes (denoted by 'fn' Cwhere 'n' is a decimal digit) under 
the (ALT) heading) is also provided at certain intersections, where deemed necessary, 
to explain extenuating circumstances considered essential to proper operation of the 
protocol, including: 


1. An exchange of QLLC link station identification information 1s ast ReAULE Se prior 
to link set-up. 
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2. The virtual call (switched virtual circuit) supporting the link connection is 
cleared (e.g., CLEAR_REQUEST or CLEAR_INDICATION) the underlying virtual circuit 
is terminated and the Q@LLC link connection placed in the INOPERATIVE state. 


3. Combined QLLC link stations assume the characteristics of either a primary or 
secondary QLLC link station upon completion of XID role negotiation. 


Sample sequences derived from the QLLC State/Action charts are shown in Figure 27 
on page II-134 as an example of how the tables may used. 


8.4.1 QLLC Stimuli 


QLLC protocol stimuli include the events, commands and responses described in the 
following paragraphs. 


8.4.1.1 Events 


LSRDY - Packet Layer (level 3) Ready: Represents a signal from the X.25 Packet Laver 
Clevel 3) that the underlying virtual circuit is in the READY (p4 or dl) state. 


LSTRT - Link_Start: Represents higher level stimulus to initiate the LLC Set-Up 
procedure for the link connection. 


LSTOP - Link_Stop: Represents higher level stimulus to initiate the LLC disconnection 
procedure for the link connection. 


LSNOP - Level_3_Inoperative: Represents a signal from the Packet Layer Clevel 3) that 
the underlying virtual circuit is INOPERATIVE. 


ERRPK - Erroneous_Packet: Represents receipt of an erroneous packet (e.g., a Q-packet 
containing an unidentifiable command/response, etc.) on the link connection. 


XCHID - Exchange_Identification: Represents a higher level request for or 
authorization to transfer link identification information. 


LTEST - Link_Test: Represents a higher level request for or authorization to transfer 
link test data. 


SDATA ~— SEND Data: Represents a higher level request for the transfer of unqualified 
user data to the packet layer (level 3) procedures. 


CLRST - Virtual Circuit CLEAR/RESET: Represents a packet level clearing of the 
virtual call, or resetting of the virtual circuit, supporting the link connection. 


LLTOX - Link_Timeout_Expiration: Represents expiration of link reply timeout, Timer 
Tq. 


8.4.1.2 Commands Sent or Received 
UDP - Unqualified Data_Packet: Represents a DATA packet with the Qualifier 'Q' bit 
equal to zero. 


QSM - Q Set Mode: Represents a Q Packet containing a Set_Mode command QLLU (QSM) itn 
the user data field. 


@pc - Q@ Disconnect (QDISC): Represents a Q_ Packet containing a Disconnect command 
QLLU CQDISC) in the the user data field. 


QxC - QQ _Exchange_Identification (QXID): Represents a Q Packet containing an 
Exchange_Identification command (QXID) in the user data field. 


QTC - Q Logical_Link_Test (QTEST): Represents a Q Packet containing a Test command 
QLLU CQTEST) in the user data field. 
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QRR - Q P’::@ive-Ready: Represents a Q Packet containing a Receive_Ready command QLLU 
CQRR) in the user data field. 


8.4.1.3 Responses Serit and Received 
QDM - @_ Disconnected_Mode: Represents a Q Packet containing: a Di sconnected_ Mode 
response QLLU (QDM) in the user data field. 


QFR - Q Frame_Reject (QFRMR): Represents a = Packet containing a Frame es ect 
response QLLU (QFRMR) in the user data field. | | 


QRD - Q Request_Disconnect: Represents a Q Packet eonteining: a peaiest snieconnuct 
response QLLU (QRD) in the user data field 


QUA = Q@ Unnumbered_Acknowledge: Represents a Q Packet containing = an 
Unnumbered_Acknowledge response QLLU (QUA) in the user data field. 


RXR - Q_Exchange_Identification (QXID): ‘Represents a Q Packet . containing an 
Exchange_Identification response QLLU (QXID}, including link station identification 
information, in the user data field. 


QTR - Q Test (QTEST): Represents a Q_ Packet containing a Link_Test response QLLU 
(QTEST), including test data, in the user data field. 


QRR - Q_ Receive-Ready: Roe eecnes. a Q. Packet containing a Reeelve _Ready response. ESE 
(QRR) in the user data field. 


C/R - CLEAR or RESET packet: Represents a clearing of the virtual call ora nesetting 
of the permanent virtual circutrt supporting the link connection by 
transmission/receipt of a CLEAR_REQUEST/CLEAR_ Snes om or 
RESET  REQUEST/RESET. INDICATION packet, respectively. ; : 


8.4.2 Actions 


Actions taken by QLLC link stations, noted = at the intersection of a 
state/condition/option and a stimulus, include those identified by a capital letter 
concatenated with a number 'L#’ (which refer to the procedures specified in §-8.3) and 
those identified by two capital letters 'LL’ defined as follows: ~ <2 


8.4.2.1 IC - Increment Retransmission Count 


Increment the (re)-transmission count and, if the retry limit has not been exceeded, 
retry the protocol procedure. Otherwise, report the failing procedure to, and await 
further direction from, the higher levels of SNA. 


8.4.2.2 IH - Inform Higher Layers 


Inform the higher layer(s) of SNA via internal signalling mechanisms. 


8.4.2.3 IP - Ignore Packet 


Ignore the received packet. 


8.4.2.4 IT - Initiate Query Timer, Tq 


Initiate a logical link timeout for the duration of Query Timer, Tq. 
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8.4.2.5 LE - Local Procedure Error 


Representing an internal signalling error or illogical protocol sequence on the part 
of the QLLC link station that may be either ignored or reported to a higher layer of 
SNA for future analysis. 


8.4.2.6 NA - Not Applicable 


Identifies events/acttions/responses that cannot occur for a given 
stece/condition/alternative. 


8.4.2.7 WNS - No Specific Action 


No specific action is required by the QLLC link station protocol. 


8.4.2.8 RE - Remote Procedure Error 


Representing a protocol procedure error on the part of the Q@LLC link station in the 
adjacent node that may be either ignored or reported to a higher layer of SNA for 
future analysis. 


8.4.2.9 RS - Report Status 


Report the current status of the Q@LLC link station to a higher level of SNA. 


8.4$.2.10 TC - Terminate Contact 


Terminate the SNA_CONTACT phase and signal CONTACTED to a higher level of SNA. 


8.4.2.11 TT - Terminate Timer Ta 


Terminate the LLC Query Timer, Tq. 
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8.5 STATE/ACTION CHARTS 


8.5.1 Balanced Link Stations 


8.5.1.1 Balanced INOPERATIVE State. 


CHART Bi-E: EVENTS in INOPERATIVE State . 


Stimuli P: CALT)| Action(s) | [LLU Transfers] 


renee ide 


XCHID 
LTEST 
SDATA 
CLRST 
LLTOX 
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CHART Bi-I: DLLUs in INOPERATIVE State 


Stimuli P: CALT)| Action(s) [LLU Transfers] 


CHART B1-S: S-format QLLUsS in INOPERATIVE State 
Stimult P: CALT)} Action(s) [LLU Transfers] 


r 
TT 
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CHART B1—-U: U-format QLLUs in INOPERATIVE State 


Stimuli P: CALT)! Action(s) [LLU Transfers] New State 


ee 
r 
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8.5.1.2 Balanced LINK_CLOSED State 


CHART B2-E: EVENTS in LINK_CLOSED State 


LSTRT NUL $1 | SM]| LINK_OPENING 
‘SMp Al, P=NUL | | - LINK_OPENING 


XCHID NUL 
OXRp 
TOXRp 
OTRp 
SMp 
ELSE 
NUL 
OXRp 
OTRp 
IOTRp 
IXOTRp 
SMp 


bad | 
it 


ELSE RS, P=NUL 


CHART B2-I: DLLUs in LINK_CLOSED State 


Stimuli P CALT) | Action(s) | CLLU Transfers] New State 


UDP NUL | 
ELSE RE, P=NUL 
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CHART B2-S: S—format QLLUs in LINK_CLOSED State 


Stimuli CALT)] Action(s) [LLU Transfers] New State 


CHART B2-U: U—format Q@LLUs in LINK CLOSED State 
Stimuli P: | 


LINK_OPENED 
LINK_OPENING 
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CHART B2-U: U—format QLLUs in LINK_CLOSED State (Continued) 


Stimuli P: CALT)| Action(s) LLLU Transfers] New State 


IXRp 
IO0XRp 
IXOTRp 
ELSE 


NUL 
ITRp 
OTRp 
IOTRp 
ITOXRp 
ELSE 
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8.5.1.3 Balanced LINK_OPENING State 


CHART B3-E: EVENTS in LINK_OPENING State 


Stimuli CALT) | Action(s) [LLU Transfers] New State 


RS, P=NUL 


RS, P=NUL 


LINK_CLOSED 
LINK_CLOSED 


LINK_RECOVERY 
LINK_CLOSED 
LINK_RECOVERY 
LINK_CLOSED 


LINK_CLOSED 


G6, P=ITOXRp 


A6, P=NUL 
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CHART B3-I: DLLUs in LINK_OPENING State 


Stimuli P: CALT)] ActicnCs) [LLU Transfers] New State { 
UDP IP | 


CHART B3-S: S-format QLLUs in LINK_OPENING State 


Stimuli Ps: CALT)]}] Action(s) [LLU Transfers] New State > 


CHART B3-U: U-format QLLUs in LINK_OPENING State 


QsM | 
OXRp 
OTRp 

RDC 


RRp 
OXRp 


LINK CLOSED 
LINK CLOSED 
LINK_CLOSED 


LINK_CLOSED 
LINK_CLOSED 
LINK_OPENED 
LINK_CLOSED 
LINK_CLOSED 


QUA 
OXRp 
OTRp 


OXRp LINK_CLOSED 

OTRp LINK_CLOSED 
QXR- 

OTRp RE, P=NUL LINK_CLOSED 
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Logical Link Control CLLC) on SNA-to-SNA Connections II-110 


NNN NMNMNNMNMNNNANMNMNMMNDMNNNMNAMMNMMNMDNM MANU NMM NAMM NMNMNNMANNNNN 


SNA/X.25 DTE/DCE Interface 


8.5.1.4 Balanced LINK_CLOSING State 


CHART B4—-E: EVENTS in LINK_CLOSING State 


Stimuli P: CALT)] Action(s) CLLU Transfers] New State 


LE 
LE 
LE 
RS 
a 


CHART B4-I: DLLUs in LINK_CLOSING State | 


Stimuli Ps: CALT)] Action(s) [LLU Transfers] 


CHART B4-S: S-format QLLUS in LINK_CLOSING State 
Stimuli P: CALT) 


INOPERATIVE 


New State 


[LLU Transfers] 


Action(s) 


New State 
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CHART B4—-U: U-format QLLUs in LINK_CLOSING State 


Stimuli P: CALT)}] Action(s) [LLU Transfers] 


RDC pee cireerennncarenntneeieistion 
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C3 | 
RE [c/R] 
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QFR 
Qxc 
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RE, P=NUL CC/R] 


8.5.1.5 Balanced LINK_RECOVERY State 


CHART B5-E: EVENTS in LINK_RECOVERY State 


Stimuli P: CALT)| Actions) [LLU Transfers] 
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CHART B5-I: DLLUs in LINK_RECOVERY State 


Stimuli P: CALT)] Action(s) [LLU Transfers] 


New State 


LINK _CLOSED 
LINK_CLOSED 
LINK_CLOSED 


LINK_CLOSED 


New State 
LINK_CLOSED 
LINK_OPENING 
LINK_CLOSING 
INOPERATIVE 


LINK_CLOSED 


INOPERATIVE 


New State 
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CHART B5-S: S-format QLLUS in LINK_RECOVERY State 


Stimuli P: CALT){ Action(s) CLLU Transfers] New State 


CHART B5-U: U-format QLLUs in LINK_RECOVERY State 


Stimuli P: CALT)} Action(s) | CLLU Transfers] New State 


RE CC/R] LINK_CLOSED 
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8.5.1.6 Balanced LINK_OPENED State 


CHART B6—-E: EVENTS in LINK_OPENED State 


Stimuli P: CALT)}1 Action(Cs) | | [LLU Transfers] | New State 7 


LE 
G3 [Qpc1| LINK_CLOSING 


XCHID NUL 


OXRp 


OTRp 

ITOXRp 
ELSE 

NUL 
OXRp 
OTRp 
IXOTRp 
ELSE 


o 


INOPERATIVE 


CHART B6-I: DLLUs in LINK_OPENED State 


Stimuli P: CALT)I Action(s) [LLU Transfers] New State 


Turi anes 


CHART B6-S: S—-format QLLUs tn LINK_OPENED State 


CALT) 


Stimuli P: Action(s) CLLU Transfers] 
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CHART B6-U: U-format QLLUsS in LINK_OPENED State 


Stimuli P: (CALT){ Action(Cs) [LLU Transfers] New State 


} QUA RE, P=NUL [C/R]| LINK CLOSED 
QDM RE [C/R]| LINK CLOSED 
QFR RE, P=NUL [C/R]| LINK _CLOSED 


E2, P=O0XRp 


LINK_CLOSED 
LINK_CLOSED 
LINK_CLOSED 
LINK_CLOSED 


LINK_CLOSED 


LINK_CLOSED 
LINK_CLOSED 


IXRp 
IOXRp 
IXOTRp 


ITRp 
ITOXRp 
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$.5.2 Primary Link Stations 


8.5.2.1 Primary INOPERATIVE State 


CHART P1I-E: EVENTS in INOPERATIVE State | 


Stimuli P: CALT){ Action(s) | — ELLU Transfers] New State | : 
L3RDY Gl, P=NUL | LINK_CLOSED | — 


rere Of OOSS 
LE 
LE 


Py 


CHART P1-I: DLLUs in INOPERATIVE State 


Stimuli P: CALT){ Action(s) [LLU Transfers] New State 


CHART P1-S: S-format QLLUs in INOPERATIVE State 


Stimuli P: CALT)} Action(s) [LLU Transfers] New State 
Oe (eee eee 
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CHART P1-U: U-format QLLUs in INOPERATIVE State 


Stimuli P: CALT)| Action(s) | sss ELLU Transfers] | New State 
AE Ok < 
Ee 
a 
a 0 
I Se 


QTC 
QTR 


r 
mr 


rf 
mr 


8.5.2.2 Primary LINK_CLOSED State 


' CHART P2-E: EVENTS in LINK_CLOSED State 


Stimuli P: (CALT)] Action(Cs) [LLU Transfers] New State 


LSTRT 
#1 Al, P=NUL LINK_OPENING 


G5, P=IXRp 


Been a 
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CHART P2-I: DLLUs in LINK_CLOSED State 
Stimuli P: CALT)}] ActionCs) a [LLU Transfers] . 


RE, P=NUL . 
RE, P=NUL. 


CHART P2-S: S-format QLLUs in LINK_CLOSED State 


Stimuli CALT)| Action(s) (LLU Transfers] 


CHART P2-U: U-format QLLUs in LINK _CLOSED State 


New State 


New State 


Stimuli CALT)}] Action(s) [LLU Transfers] 


25M RE, P=NUL | [C/R] 
QDc RE, P=NUL [C/R] 


Fit corres eceiciocronecamnrotrtoor ats 
rei et 
a 


QXR IXRp G7, P=NUL 
ELSE RE, P=NUL 


G8, P=NUL 


New State 


RE, P=NUL 
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8.5.2.3 Primary LINK_OPENING State 


CHART P3-E: EVENTS in LINK_OPENING State 
Stimuli P: 


LINK_CLOSED. 


A6, P=NUL INOPERATIVE 
~LLTOX 


CHART P3-I: DLLUs in LINK_OPENING State 


Stimuli P: CALT)1 Action(s) CLLU Transfers] New State 
UDP 


RE LINK_CLOSED 
RRp 


CHART P3-S: S-format QLLUs in LINK_OPENING State 


Stimuli P: CALT)}] Action(s) CLLU Transfers] New State 
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CHART P3-U: U-format QLLUs in LINK_OPENING State 


Stimuli P: CALT)] Action(s) CELLU Transfers) | New State 


LINK OPENED 
| LINK_OPENED 


Q@DdC 
ae 
Terris 


or 


an: 


8.5.2.4 Primary LINK_CLOSING State 


Stimuli P: (ALT)| Action(s) | ———s—sELLU Transfers] | New State 


LTEST 
SDATA 
CLRST 
LLTOX 


- = 
m m 


rc” 
mm 


| aed 
m 


LINK_CLOSED 
CQDC] 


bd ‘ai a 
oO mim 


CHART P4—-I: DLLUs tn LINK_CLOSING State 
Stimuli P: CALT)| Action(s) | [LLU Transfers] New State | 


CHART P4-S: S-format QLLUs in LINK_CLOSING State 


Stimuli P: (ALT) Action(s) [LLU Transfers] New State 
peRR OP Ed 
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CHART P4-U: U-format QLLUs in LINK_CLOSING State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
[C/R] LINK. CLOSED 
[C/R] LINK CLOSED 


LINK_CLOSED 


LINK_CLOSED 


wa 
m 


adc 


Aa 
m 


QFR 
Qxc 
QXR 
QTC 
QTR 


ry * 
wm 


[C/R] LINK_CLOSED 


A 
mi 


Ai A! vA 
mim, m 


8.5.2.5 Primary LINK_RECOVERY State 


LINK_RECOVERY state is Not Applicable to Primary QLLC link stations. 
8.5.2.6 Primary LINK_OPENED State 


CHART P6—-E: EVENTS tn LINK_OPENED State 


a 


| El, P=IXRp 


SDATA NUL 
ELSE 


ot a 


LINK_CLCSED 
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CHART P6-I: DLLUs in LINK_OPENED State i ee a 
Stimuli P: CALT)| Action(s) CLLU Transfers] | New State | 


ee ? : ‘ . . 3 ‘ ‘ ‘ 


CHART P6—-S: S—format QLLUs in LINK_OPENED State. 2. s |. 
Stimuli P: CALT)| Action(s) . _— [LLU Transfers] New State 
CHART P6-U: U-format QLLUs in LINK_OPENED State 


Stimuli P: CALT)| Action(s) -[E{LLU Transfers] | New State . 
, ) | LINK_CLOSED 


| [c-R] 


RE, P=NUL ; i . CC/R]| -LINK_CLOSED 


Cl, P=NUL 43 C1| LINK_CLOSING 


DC : 
RD 
IXR 
—OETR | 
FR : ; | 
XC 
XR 
QTC 
QTR 


IXRp RE, P=NUL : 


RE, P=NUL |  EevrRI|) LINK CLOSED 


— ? LINK_CLOSED 
IXRp G7, P=NUL : : ; : 


} etc IXRp | RE, P=NUL | a, — €C/RI|  LINK_CLOSED 


a ee RJ] LINK_CLOSED — 
ITRp G8, P=NUL | 


Q 
Q 
Q 3] LINK CLOSED 
Q 
Q 
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8.5.3 Secondary Link Stations 


8.5.3.1 Secondary INOPERATIVE State 


CHART S1-E: EVENTS in INOPERATIVE State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
LINK_CLOSED 


CHART S1-I: DLLUs in INOPERATIVE State 


Stimuli P: CALT){ ActionCs) {LLU Transfers] | New State 


CHART S1-S: S—format QLLUS in INOPERATIVE State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
SS ES 
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CHART S1-U: U-format QLLUs in INOPERATIVE State 


Stimuli P: (ALT) Action(s) [LLU Transfers] 


apc 


| cased 
m 


| soa 
m 


QRD 


rr 
mr 


~ me ae 
m m } mi 


QFR 
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| eed 
mi 
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Q 
QTR 


Cc 
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8.5.3.2 Secondary LINK_CLOSED State 


CHART S2-E: EVENTS in LINK_CLOSED State 


Stimuli P: CALT) Action(s) [LLU Transfers] 


LSTRT 
LSTOP 


G7, P=NUL 


G8, P=NUL 


RE, P=NUL 
RE, P=NUL 


CHART S2-I: DLLUs in LINK_ CLOSED state 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
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CHART S2-S: S-format Q@LLUs in LINK_CLOSED State 


Stimuli P: Action(s) [LLU Transfers] New State 


CHART S2-U: U-format QLLUs in LINK —SLOSED State 


Stimuli CALT)}] Action(Cs) [LLU Transfers] New State 


RE, P=NUL 
RE, P=NUL 


QUA 
QRD 


E2, P=OXRp 
RE, P=NUL 
RE, P=NUL 


F2, P=OTRp 


RE, P=NUL 


RE, P=NUL 
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8.5.3.3 Secondary LINK_OPENING State 


CHART S3-E: EVENTS in LINK_OPENING State 


riser id 
onan 


ERRPK | | LINK_RECOVERY 
a eet 


LINK_CLOSED 
XCHID | 
| OXRp 


LTEST 


LINK_CLOSED 
LINK _CLOSED 
LINK_CLOSED 


CHART S3-I: DLLUs in LINK_OPENING State 


Stimuli P: CALT)] Action(s) [LLU Transfers] New State 
UDP LINK_CLOSED 
or | | | 

CTp RE, P=NUL | LINK_CLOSED 
CHART S3-S: S-format QLLUs in LINK_OPENING State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 


QRR 


CTp TC, P=NUL | LINK_OPENED 
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CHART S3-U: U-format QLLUs in LINK_OPENING State 


Stimuli Ps: CALT)1 Action(s) [LLU Transfers] New State 


A2 [QUA] LINK_OPENED 
A2, P=CTp CQUA] 


LINK_CLOSED 


RE [C/R]} LINK_RECOVERY 
or RE CC/R] LINK_CLOSED 
E2, P=0XRp 
or RE CC/R] LINK_CLOSED 


F2>, P=OTRp 
RE [C/R] LINK_CLOSED 


8.5.3.4 Secondary LINK_CLOSING State 


a 
[es 
RS 


L3NOP INOPERATIVE 


LINK_RECOVERY 
LINK_CLOSED 


G7, P=NUL 


G8, P=NUL 


CHART S4-I: DLLUs in LINK_CLOSING State 


Stimuli P: CALT)} Action(s) [LLU Transfers] New State 
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CHART S4-S: S—format Q@LLUs in LINK_CLOSING State 


Stimuli P: ‘CALT)| Action(s) | [LLU Transfers] 


CHART S4-U: U-format QLLUs in LINK_CLOSING State 


Stimuli P: CALT)] Action(s) CLLU Transfers] 


RE — [C/R] 
RS | [QUA] 
NA | 

RE [C/R] 


RE CC/R] 


rem 
Teun 
ree 
leon 


8.5.3.5 Szcondary LINK_RECOVERY State 


CHART S5—-E: EVENTS in LINK_RECOVERY State 


LSTOP G3 | [QRD] 
L3NOP RS 
RS 


or {| RS CQFR] 
XCHID 


G7, P=NUL 
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New State 
LINK_CLOSED 
LINK_CLOSED 


LINK_CLOSED 


LINK_CLOSED 


New State 
LINK_CLOSED 
LINK_OPENING 
LINK_CLOSING 
INOPERATIVE 


LINK_CLOSED 


LINK_CLOSED 
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CHART S5-I: DLLUs in LINK_RECOVERY State 


Stimuli P: CALT)| Action(s) (LLU Transfers] New State 


CHART S5-S: S—-format QLLUsS in LINK_RECOVERY State 


Stimuli P: CALT)| Action(s) PED Teeneters] 


CHART S5-U: U-format Q@LLUs in LINK_RECOVERY State 


Stimuli P: CALT){| Action(s) [LLU Transfers] New State 
LINK_CLOSED 


apc 
a 
a a 
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8.5.3.6 Secondary LINK_OPENED State 


CHART S6—-E: EVENTS in LINK_OPENED State 


Stimuli P: (CALT)] Action(s) CLLU Transfers] New State 


LSTRT 


LINK_CLOSING 
LINK_CLOSING 
LINK_CLOSING 
- INOPERATIVE 
INOPERATIVE 
INOPERATIVE 
LINK_RECOVERY 
LINK_CLOSED 
LINK_RECOVERY 
LINK_CLOSED 
LINK_RECOVERY 
LINK_CLOSED 


G3, P=NUL 


SDATA NUL 
OXRp 
OTRp 
ELSE 
LINK_CLOSED 
LINK_CLOSED 
LINK_CLOSED 


RS, P=NUL 


RS, P=NUL 
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CHART S6-I: DLLUs in LINK_OPENED State 


Stimuli P: CALT)}] Action(s) [LLU Transfers] New State 


RE, P=NUL LINK_CLOSED 


RE, P=NUL | LINK CLOSED 


CHART S6-S: S-format QLLUs in LINK OPENED State 
Stimuli P: CALT)| Actions) [LLU Transfers] 


CHART S6—-U: U-format QLLUs in LINK_OPENED State 


Stimuli P: CALT)! Action(s) [LLU Transfers] New State 
QbdCc | C3 CQUA] LINK_CLOSED 


RE, P=NUL 


LINK_CLOSED 
LINK_CLOSED 


RE, P=NUL 


RE, P=NUL 


LINK_CLOSED 
LINK_CLOSED 
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8.6 SAMPLE QLLC SEQUENCES 


QLLC sequences for “typical” error free peer-to-peer, link activation, 
initialization, data transfer, disconnection and deactivation dertved from the charts 
in "Balanced Link Stations™ on page II-104 and Ceprered in Pigure 27 on page cil 134% 
are described as follows. 


1. Q@LLC link stations, upon recognition of a transition of the supecet ina: logical 
channel (virtual call or permanent virtual circuit) to the READY state (LIRDY 
event), become operative (G1), signal adapter enabled (CEABLD) to the upper 
layer(s) of SNA and place the underlying link connection in the LINK_CLOSED state. 


2. An SNA_CONTACT results in the upper layer(s) of SNA requesting an exchange of link 
Station identification information (CXIDFR) causing the QLLC link station to 
initiate an exchange of link station identification information (G5) by 
transferring an Exchange_Identification command QLLU (QXC) and set P=IXRp 
Cincoming link station identification information pending). 


QLLC link stations, upon receipt of the QXID command [QXC] in the LINK_CLOSED 
state inform a higher layer of SNA CIH), passing the link station identification 
information contained in the information field of the received QLLU (DATA), sets 
P= ae Coutgoing link identification information pending) and may start Query 

Timer Taq. 


3. QLLC link stations in adjacent nodes with P=0XRp (Coutgoing identification 
information pending), when authorized by the upper layer(s) of SNA CXRSPR), 
respond to the received QXID command (G7) by transferring a QXID response [QXR] 
containing their link station identification information in the information 
field, set P=SMp (link set mode pending) and stop the Query Timer, Tq, if it is 
running. 


QLLC link stations with P=IXRp Cincoming link identification tnformation 
pending), upon receipt of the Q@XID response [QXR] inform the upper layer(s) of SNA 
CIH) passing the identification information contained in the information field of 
the received QLLU (DATA) and set P=SMp Clink set mode pending). 


When authorized by the upper layer(s) of SNA C(CLSTRT) QLLC link stations with P=SMp 
Clink set mode pending) initiate the link setup procedure (Al) by transferring a 
Set_Mode command QLLU, set P=NUL, place the underlying link connection in the 
LINK_OPENING state and may initiate a timeout for the duration of Query Timer, Tq. 


Upon receipt of the Set_Mode command QLLU (QSM), QLLC link stations with P=SMp 
Clink set mode pending), respond to the received QSM command (CA2) by transferring 
an Unnumbered_Acknowledge response QLLU [QUA], set P=CTp and place the link 
connection in the LINK_OPENING state. 


Upon receipt of the QUA response, QLLC link stations on connections perceived to 
be in the LINK_OPENING state with P=SMp Clink set mode pending), tnform the upper 
layer(s) of SNA CIH) by signalling CONTACTED, transfer a Receive _Ready command 
QLLU CQRR) informing the communicating link station in the adjacent node to 
terminate the CONTACT phase, set P=NUL, place the link connection in the 
LINK_OPENED state and stop the Query Timer, Tq, if it is running. 


Upon receipt of a QRR command, QLLC link stations in adjacent nodes on connections 
perceived to be in the LINK_OPENING state with P= CTp, inform the higher layer(s) 
of SNA (IH), set P=NUL and place the link connection in the LINK_OPENED state. 


4. QLLC link stations on connections itn the LINK_OPENED state with P=NUL exchange 
C[DLLUJs on behalf of the upper layer(s) of SNA as requested (DTRFRC(DATA)) via the 
logical channel (virtual call or permanent virtual circuit) supporting the link 

connection and respond to QLLUS and internal stimuli as previously specified in 

0. 


5. An SNA DISCONTACT results in the upper layer(s) of SNA requesting a link 
termination (CLSTOP) causing QLLC link stations to initiate a link disconnection 
procedure (G3) by transferring a Disconnect command QLLU [QDC] placing the link 
connection in the LINK_CLOSED state. 


Upon receipt of a QDISC command (QDC), QLLC link stations on connections perceived 
to be in the LINK_OPENED state with P=NUL, inform the higher layers of SNA (IH) by 
signalling INOP_LNK, respond to the received Q@DISC command (C3) by transferring a 
QUA response and place the underlying link connection in the LINK_CLOSED state. 
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“pon receipt of a QUA response on a link connection perceived to be in the 
LINK_CLOSING state, QLLC link stations on connections with P=NUL, inform the 
higher layer €s) of SNA (CIH) by signalling +RSP and place the underlying link 
connection in the LINK_CLOSED state. 


6. Uron receipt of a signal from the Packet Layer (Level 3) that the supporting 
logical channel Cvirtual call or permanent virtual circuit) is in the INOPERATIVE 
state (CL3NOP) QLLC link stations place the associated link connection in the 
INOPERATIVE state and report this status (RS) to the higher layer(s) of SNA by 
signalling adapter disabled (DABLD). 

In Figure 27 on page II-134: 
a. Time progresses from top to bottom of the figure. 


b. The various layers at the origin and destination DTEs are represented by 
vertical lines. 


c. QLLC link station states are represented by their abbreviated names in the 
vertical line representing the logical link control (LLC) layer. 


d. Signal and data flows are represented by horizontal lines with arrowheads 
denoting the direction of flow. | 


e. External stimuli are represented by labels above the origin end of the flow 
lines and numbers enclosed in brackets [#] as described above. 


f. QLLC actions and state transitions are shown above the origin end of the flow 
lines and the resulting command/response/signal transferred is shown below 
the arrowhead denoting direction of flow; and, 

e DABLD - represents an Adapter Disabled Signal. 
e EABLD - represents an Adapter Enabled Signal. 
e ULSNA - represents the Upper Layer(s) of SNA. 


e X25PL 


represents the Packet Layer of X.25. 


Logical Link Control (LLC) on SNA-to-SNA Connections II-133 


SNA/X.25 DTE/DCE Interface 


ORIGINATION DESTINATION 


LOGICAL LINK STATIONS 


Cc X25PL X25PL L 
PSDN(s) 


ULSNA L Cc! ULSNA 


LOGICAL 
CHANNEL'S | 


oe Foe SIGNAL 


SIGNAL 


{2]— 


t3]— 


C4]— 


<— 
DATAIN 


[5i— VARYOFF 


[6J]— 


Figure 27. QLLC_Flows: Exchange ID, Link Set-Up, Data Transfer and Link 
Disconnection 
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9.0 OTHER SYSTEM CONSIDERATIONS 


9.1 SECURITY 


9.1.1 SNA-to-SNA Connections 


Called DTEs can implement a rudimentary calling DTE identification check by testing 
the calling DTE address in INCOMING CALL packets. DTEs can elect to implement as a 
user option the connection identifier capability defined for CALL REQUEST and INCOMING 
CALL packets. 


Care must be exercised in choosing cryptographic techniques. Data link control level 
cryptographic products defined for SNA procucts are not defined for the X.25 link and 
packet levels and cannot be used. Cryptographic products defined for SNA above, and 
transparent to, the data link control level can be used. 


9.1.2 SNA-to-non SNA Connections 


Security techniques are specific to the particular non-SNA remote DTE being supported. 
In general, techniques used for SNA-to-SNA connections are not applicable. 


9.2 RELIABILITY, AVAILABILITY AND SERVICEABILITY (RAS) 


RAS characteristics of PSDNs are not clearly established. However, numerous error 
detection and reporting mechanisms are included throughout this interface 
specification to aid in problem determination. 


9.2.1 Philosophy 


The fundamental philosophy adopted for error reporting in PSDN environments its one of 
commonality. IBM SNA X.25 DTEs cover ae broad spectrum of RAS capabilities. 
Therefore, reporting to a higher level may mean different things for different 
products. These can range from simply reporting an error condition to the local 
operator of a simple DTE to full compatibility with Network Problem Determination and 
Analysis programs. 


A common set of Diagnostic Codes is specified in Appendix F for use by all IBM SNA X.25 
DIEs in reporting error conditions and abnormal situations to higher levels of SNA. 


§.2.2 Summary of Error Conditions 


Detectable error conditions are divided into four general categories: 


1. those resulting from receipt of unsupported packet types (i.e., DCE INTERRUPT or 
DCE DATAGRAM packets). 


2. those that can result from a discrepancy between the DTE and DCE interpretations 
of the state of some subscribed interface parameter. Ci.e., receipt of an 
INCOMING CALL packet ona logical channel assigned for permanent virtual circuit 
service); and 


3}. those most likely resulting from a malfunction of the DCE (ij.e., receipt of an 
unsolicited DCE RESTART CONFIRMATION packet); 


§. those caused by failures at the physical level or the link level. Ci.e., dropping 
of the Data Set Ready indication). 
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IBM SNA X.25 DTEs, upon detection of errors in category: 


"1" or °2' - clear the virtual call or reset the permanent virtual circuit if such 
an action is permitted without violating any procedure. The error condition is 
reported to a higher level of SNA; the received packet is discarded. | 
"3" - transmit a RESTART REQUEST packet across the DTE/DCE interface, place all 


virtual circuits in an inoperative state and report the error condition to the 
higher levels of SNA. 


"4" - place the LAPB link and all virtual circuits at the DTE/DCE interface in an 
inoperative state and report an interface failure to a higher level of SNA. 


9.2.3 General Recommended Actions 


Errors detected at the X.25 DTE/DCE interface, either by IBM SNA X.25 DTEs or their 
associated DCEs, that result in CLEAR, RESET or RESTART indications must be reported 
to the SNA control point or to the local operator, as appropriate. The Call Progress 
Signals (CPS) defined in CCITT Recommendation X.96 used for "Network Generated’ Cause 
and Diagnostic Codes defined in CCITT Recommendation X.25 and a common set of 'DTE 
Originated’ diagnostic codes defined in Appendix F for IBM SNA X.25 DTEs to aid in 
problem determination are used for reporting purposes. Session outage notifications 
are propagated in accordance with general SNA mechanisms, using INOPERATIVE CINOP) to 
the control point and RECORD FORMATTED MAINTENANCE STATISTICS CRECFMS) or RECORD 
MAINTENANCE STATISTICS CRECMS) to Communication Network Management 
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A.0 APPENDIX A: ASSIGNMENT OF LOGICAL CHANNELS 


Range A logical channels used for virtual calls and permanent virtual circuits (text 
deleted). 


A.1 LOGICAL CHANNEL ASSIGNMENT 


Logical channel number one (x'001') is used by DTEs that support a single logical 
channel. 


A range of logical channels must be agreed upon with network Adminjstrations for 
multiple logical channel DTE/DCE interfaces, according to Figure A-1l. 


L_Cc_I 


Reserved 


Permanent Virtual Circuits (Text deleted) 


One-Way 
Incoming 


Virtual Calls 
CSwitched Virtual Circuits) 


Two-way 


One-Way 
: Outgoing 
HOC 


. Non—Assigned 
4095 


Figure A-1l. Assignment: Logical Channels 


With reference to Figure A-1: 


0 is a logical channel reserved exclusively for the transmission of RESTART and 
DIAGNOSTIC packets. 


1 to LIC-1 is the range of logical channels assigned for permanent virtual 
circuits. 


LIC to HIC is the range of logical channels assigned to one-way incoming logical 
channels for virtual calls (see §-7.1.8). 


LTC to HTC is the range of logical channels assigned to two-way logical channels 
for virtual calls. 


LOC to HOC is the range of logical channels nee aoee to one-way outgoing logical 


channels for virtual calls (see §-7.1.7). 


HIC+1 to LTC-1, HTCt+1 to LOC-1, and HOCt+1 to 4095 are unassigned logical channels. 


Note: 


Ls 


Logical channels are numbered according to a set of contiguous numbers ranging 
from 0 Clowest) to 4095 Chighest) using 12 bits made up of a four (4) bit Logical 
Channel Group Number (see §-6.1.2). and an eight (8) bit Logical Channel Number 
(see §-6.1.3). Logical channel numbers are binary coded in bit positions four (4) 
through one (1) of octet one (1) followed by bit positions eight (8) through one 
C1) of octet two (2) with bit one (1) of octet (2) being the low order bit. 
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2. All logical channel boundaries are agreed upon with the network Administration for 
a period of time. 


3. To avoid frequent rearrangement of logical channels, not all logical channels 
within the range allocated for permanent virtual circuits are necessarily 
assigned. 


4. In the absence of permanent virtual circuits, logical channel number one is 
available for LIC. In the absence of permanent virtual circuits and one-way 
incoming logical channels, logical channel one is available for LTC. In the 
absence of permanent virtual circuits, one-way incoming logical channels and 
two-way logical channels, logical channel one is available for LOC. 


5. DCEs use the lowest numbered logical channel in the READY state in the range LIC to 
HIC and LTC to HTC as the logical channel for new incoming calls. ee 


6. To minimize the risk of call collision, DTEs use the highest numbered logical 


channel tn the READY state for outgoing calls. DTEsS may use either two-way 
logical channels or one-way outgoing logical channels. 
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B. APPENDIX B: PACKET LEVEL STATE DIAGRAMS 
Packet level DTE/DCE interface state diagrams 


B.1 SYMBOL DEFINITION OF THE STATE DIAGRAM 


Transition | 
> 


DTE 
1a Responsibility for the transition 


State name 


| 
PACKET TYPE } Packet transmitted 


> 
Transttion 


Note: 


|} 1. States are represented by boxes wherein the state name and number are indicated. 


2. State transitions are represented by arrows. The station (DTE or DCE) responsible 
for the transition and the packets transferred is indicated inside the arrow. 


B.2 ORDER DEFINITION OF THE STATE DIAGRAMS 


The normal procedure at the DTE/DCE interface is described in a number of small state 
diagrams. To. describe the normal procedure fully it is necessary to allocate a 
priority to the different figures and to relate a higher order diagram with a lower 
one. This is done by the following means: 


e The figures are arranged in order of priority with Figure B-1 (Restart) having the 
highest priority and subsequent figures having lower priority. Priority means 
that when a packet belonging to a higher order diagram is transferred, that 
diagram is applicable and the lower order one is not. 


° The relation with a state in a lower order diagram is given by including that state 
inside a box in the higher order diagram. 
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READY 
DTE pi or dl DCE 
(Note 1) 
RESTART RESTART 
REQUEST INDICATION 
DCE 
RESTART 
CONFIRMATION CONFIRMATION 
or 
RESTART 
INDICATION 
V 
r2 DCE r3 


DTE RESTART 


DTE REQUEST 


DCE RESTART 
INDICATION 


DCE 


RESTART RESTART 
REQUEST INDICATION 
(Note 3) (Note. 2) 


Note: 


1. State pl is for virtual calls and state dl is 


circuits. 


for permanent virtual 


2. This transition 
3. This transition 


Figure B-1. States 


may take place after time-out T10. 
may take place after a 200 second time-out. 


for the Transfer of RESTART packets 
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DTE DCE 


CALL INCOMING 
REQUEST CALL 


DCE++ --------— 4 REQUEST -F-------- DTE 


DCE WAITING 


DCE A DTE 
INCOMING CALL 
CALL REQUEST 
pS 
CALL 
CALL COLLISION CALL 
CONNECTED ACCEPTED 
DCE 
CALL 
CONNECTED 


di 
FLOW CONTROL READY 


pP4 
DATA TRANSFER 


Note: This transition may take place after a 200 second time-out. 


Figure B-2. States for the Transfer of Call Set-Up Packets within the 
PACKET LEVEL READY Crl1) State 
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ANY STATE | 
except 


p6 or p7 


—— | 


CALL. ap ss eee REQUEST CLEAR 
CONNECTED DTE CLEAR (Note 5) INDICATION DCE CLEAR 


or 

(Note 1) REQUEST (Note 3) INDICATION CALL 
REQUEST 
A DCE A | A DTE A (Note 4) 


DCE DTE 
CLEAR CONFIRMATION CLEAR CONFIRMATION 


or or 
. DCE | CLEAR REQUEST 
CLEAR INDICATION 


CLEAR CLEAR 
REQUEST INDICATION 
DCE V DTE DCE V ODTE CALL 
ACCEPTED 
p CLEAR ie 2) 


Notes: 


1. This transition is possible only if the previous state was DTE 
WAITING (p2). 


2. This transition is possible oniy if the previous state was DCE 
WAITING (p3). 


3. This transition may take place after Time-out T13. 


4. This transition is possible only if the previous state was READY (pl) 
or DCE WAITING (p3). 


5. This transition may take place after a 200 second time-out. 


Figure B-3. States for the Transfer of Call Clearing Packets within the 
PACKET LEVEL READY (rl) State 
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DTE DCE 


FLOW CONTROL READY 


RESET RESET 
INDICATION REQUEST 
RESET or or RESET 
REQUEST DCE DTE INDICATION 
RESET RESET 


CONFIRMATION CONFIRMATION 


DCE DTE 


DTE DTE RESET 


. > DCE RESET DCE 
REQUEST INDICATION 
RESET RESET 
REQUEST . INDICATION 


(Note 2) (Note 1) 


Note: 


1. This transition may take place after time-out Tl12. 


2. This transition may take place after a 200 second time-out. 


Figure B-4. States for the Transfer of RESET Packets within the 
DATA TRANSFER (Cp4) State. 
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THIS PAGE 


INTENTIONALLY 
BLANK 
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C.0 APPENDIX C: DCE PACKET LEVEL ACTIONS 


Actions taken by the DCE on receipt of packets in a given state of the packet level 
DTE/DCE interface as perceived by the DCE. 


C.1 DCE STATE/ACTION TABLES 


TABLE C_1: Special Cases 


Numbers. following a # are diagnostic codes in decimal notation. 
(See Appendix E) 


Packet from the DTE. Any State 
Any packet with packet length less than 2 octets DIAG #38 
Any packet with incorrect General Format Identifier (GFI) DIAG #40 


Any packet other than RESTART_REQUEST or CONFIRMATION on DIAG 
unassigned logical channel or LCI = x'000! #36 


Any packet with correct GFI and See Table 
assigned logical channel C_2 


DIAG: DCEs discard the received packet and, on networks that implement 
diagnostic packets, transmit a DIAGNOSTIC packet contatning the indicated 
diagnostic code to the DTE. 


There may be more than one error associated with a packet. Networks stop normal 
processing of packets when an error is encountered. Thus, only one diagnostic code 
is indicated in DIAGNOSTIC packets. The order of packet de-coding and checking is 
not standardized among networks. 
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Table C_2: DCE actions on Receipt of packets in a given state of the 
packet level DTE/DCE interface as perceived by the DCE: 
Restart Procedure for assigned logical channels 


The figures in parentheses () are the new states to be entered. 
Figures following a # are diagnostic codes in decimal notation. 
(Note 1). 


State of the 
interface as 


PACKET DTE DCE. 


perceived by LEVEL RESTART RESTART 
Packet from | the DCE READY REQUEST INDICATION 
the DTE with ri r2 r3 . 


assigned logical 
channel 


RESTART REQUEST NORMAL DISCARD NORMAL 
C(r2) Cr2) (pl ur dl) 
Note 2 


DTE RESTART CONFIRMATION 


ERROR ERROR NORMAL 
Cr3) C(r3) Cpl or dl) 
#17 #18 Note 2 


DATA, CINTERRUPTJ, CALL SET-UP and See ERROR DISCARD 
CLEARING, FLOW CONTROL Table Cr3) Cr3) 
or RESET C_3 #18 


RESTART REQUEST OR DTE RESTART See ERROR DISCARD 
CONFIRMATION WITH BITS 1 to 4 of Table Cr3) (r3) 
OCTET 1 or BITS I to 8 of OCTET 2 C_3 #41 


NOT EQUAL TO ZERO 


PACKETS HAVING A PACKET TYPE See DISCARD 
IDENTIFIER WHICH IS SHORTER THAN 1 Table Cr3) 
OCTET OR IS NOT SUPPORTED BY THE DCE C_3 #38 #33 


NORMAL: DCEs follow the procedures defined in §-3. When RESTART_REQUEST packets 

or DTE_RESTART_CONFIRMATION packets received in state r3 exceed the maximum 
permitted length, DCEs invoke the ERROR procedure with diagnostic #39 and enter 
state r3. When RESTART_REQUEST packets received in state rl exceed the maximum 
permitted length, the action taken by DCEs is for further study. 


DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. 


ERROR: DCEs discard the received packet and indicate a restarting by transmitting 
a RESTART_INDICATION packet, with the cause, "Local Procedure Error™ (diagnostic per 
Table C_2). On virtual calls, the remote DTE is informed of the restarting by a 
CLEAR_ITNDICATION packet, with the cause "Remote Procedure Error" (same diagnostic). 
On permanent virtual circuits, the remote DTE is informed by a RESET_INDICATION 
packet, smith the cause "Remote Procedure Error" (same diagnostic). 


When a RESTART_INDICATION is issued as a result of an error condition in state r2, 
DCEs eventually consider the DTE/DCE interface to be in the PACKET LEVEL READY state 
(rl). Eventually consider is interpreted to mean after sixty (60) seconds. 


Note: 


1. There may be more than one error associated with a packet. Networks stop normal 
processing of packets when an error is encountered. Thus, only one diagnostic 
code 315 associated with an error indication by DCEs. The order of packet 
de-coding and checking on networks is not standardized. 


2. State pl for logical channels assigned to virtual calls; or, dl for logical 
channels assigned to permanent virtual circuits. | 
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TABLE C_3: Actions by DCEs on Receipt of Packets in a given State of 


the Packet Level DTE/DCE Interface as Perceived by the DCE: 
Call Setup and Clearing on Assigned Logical Channels. 


The letters and numbers in (ln) are the new states to be entered. 
Numbers following a # are diagnostic codes in decimal notation (Note 1). 


PACKET LEVEL READY rl 


‘Interface 
States as 
perceived 
by the DCE 


| DTE CLEAR|DCE CLEAR 
TRANSFER;| COLLISON] REQUEST eS al 
p5 p 


Note 2,3 


READY |WAITING|WAITING 
pl 


Packet on 
assigned 
LCI 


Note 3] Note 2 


CRQ ERROR NORMAL ERROR ERROR | DISCARD 
(p7) (p5) Cp7) (p7) (p7) 
#21 Note 4 #24 #25 


ERROR ERROR NORMAL ERROR ERROR DISCARD 
(p7) (p7) (p4) (p7) Cp7) (p7) 
#20 #21 Note 6 $24 #25 
ERROR 
(p7) #42 
Note 7 


NORMAL] NORMAL| NORMAL NORMAL NORMAL DISCARD NORMAL 
(p6) (p6) (p6) Rhee (p6) Cp6) (pl) 
ote: 


(p7) (p7) (p7) 
#20 #21 #22 


DIR|FC | ERROR | ERROR ERROR 
| =Cp7) (p7) (p7) 
#20 #21 #22 


wilt 
Tce ERROR ERROR ERROR ERROR ERROR NORMAL 
(p7) (p7) (pl) 
#24 #25 


ERROR ERROR DISCARD 
(p7) (p7) (p7) 
#24 #25 


IRR|TIR ERROR ERROR ERROR ERROR ERROR DISCARD 
w/LCI#0 (p7) Cp7) (p7) ee (p7) (p7) 
4 #41 


See DISCARD 
Table (p7) 
C_4 


—CRQ: CALL_REQUEST 

CAC: CALL_ACCEPTED 

CLR: CLEAR_REQUEST 

TCC: DTE_CLEAR_CONFIRMATION 
DIR|FC: DATA, CINTERRUPT,] RESET or FLOW_CONTROL 
IRR|TIR: RESTART_REQUEST or DTE_RESTART_CONFIRMATION 


UNK|NUP: Packets having a Packet Type Identifier shorter than one octet or that 
are not supoorted by the DCE. | 


— LCI: Logical Channel Identifier (bits 1-4 of octet #1 plus bits 1-8 of octet 


NORMAL: DCEs follow the procedures defined in §-4. For packets exceeding the 
maximum permitted length, DCEs invoke the ERROR procedure with diagnostic #39 and 
enter state p/7. | 
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DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. 


ERROR: DCEs discard the received packet and indicate a clearing by eeansmrecias a 
CLEAR INDICATION packet, with the cause "Local Procedure Error” (diagnostic per Table 
C_3). On virtual calls, the remote DTE is’ informed ‘of the clearing by ase 
CLEAR_ INDICATION packet, with the cause "Remote Procedure Error™ (same diagnostic). 


It is required that itn the absence of. an appropriate DTE response to a 
CLEAR_INDICATION packet issued as a result of an error condition in state p6,: the DCE 
should eventually consider the DTE/DCE interface to be in the READY state (pl). 
Eventually consider is interpreted to mean after sixty (60) seconds. 


Note: 


1. There may be more than one error associated with a packet (e.g., packet too long 
and transmitted in a wrong state). Networks stop processing of packets when an 
error is encountered. Thus, only one diagnostic code is associated with an ERROR 
indication by DCEs. The order of packet de-~coding and checking is not 
standardized among networks. 


2. eee does not exist for one-way logical channels outgoing (as perceived by 
5). 


3. Ue ae does not exist for one-way logical channels incoming (Cas Procenveg by 
Ss 


a. For one-way logical channels incoming Cas perceived by DTEs) DCEs transmit a 
CLEAR_INDICATION packet with the cause "Local Procedure Error” and diagnostic 
code #34. 


b. DCEs transmit a CLEAR INDICATION packet when a CALL REQUEST packet contains an 


improper address format or facility field; call progress signals and 
diagnostic codes are listed below: 


ERROR CONDITION CAUSE DIAG 


1. Address contains a non BCD digit LPE 67,68 
2. Prefix digit not supported LPE 67,68 
3 National address smaller than 

national address format permits LPE 67,68 
4 National address larger than 

national address format permits LPE 67,68 
5. DNIC less than four digits LPE 67,68 
6. Facility length larger than 63 LPE 64 
7. \No combination of facilities 

could equal facility length LPE 64 
8 Facility length larger than 

remainder of packet LPE 38 
9 Facility values conflict (€e.g., 

a particular combination not 

supported) LPE 66 
10. Facility code not allowed IFR 65 
ll. Facility value not allowed IFR 66 

LPE Local procedure error 


IFR 
DNIC 


Invalid facility request 
Data Network Identification Code 


c. DCEs transmit a CLEAR_INDICATION packet when a remote DTE makes a procedure 
error, either for one of the above reasons associated with its call 
acceptance, or because of an expired timeout (diagnostic #49). 


5. For permanent virtual circuits, DCEs discard the received packet and indicate a 


reset by transmitting a RESET_INDICATION packet, with the cause "Local procedure 
error™ (diagnostic #35). The remote DTE is informed of the reset by a 
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RESET_INDICATION packet, with the cause "Remote Procedure Error” (same 


diagnostic). 


Text deleted. 


6. The ERROR procedure is invoked by DCEs when CALL_ACCEPTED packets contain an 
Improper address format or facility field. Examples are similar to those in Note 


G4 point (b) above. 


7. ##=The presence of the Fast Select facility, indicating restriction on response in an 


INCOMING CALL packet prohibits the DTE from sending a CALL_ACCEPTED packet. 


Actions taken by the DCE on Receipt of Packets in a given 
State of the Packet Level DTE/DCE Interface as Perceived 
by the DCE: Data Transfer (Flow Control and Reset) on 
Assigned Logical Channels 


TABLE C_4: 


The figures in parentheses () are the new states to be entered; the 
figure following a # is the diagnostic code in decimal notation 


(Note 1). 
DATA TRANSFER p4 


State of the interface 
FLOW CONTROL DTE RESET DCE RESET 


as perceived by 
Packet from the DCE 

RE REQUEST INDICATION 
d2 


the DTE with ADY 
assigned logical channel di d3 
RESET REQUEST NORMAL DISCARD NORMAL 
(d2) (d2) (di) 
DTE RESET CONFIRMATION ERROR ERROR NORMAL 
(d3) #27 (d3) #28 (dl) 
DATA, CINTERRUPT] OR NORMAL ERROR DISCARD 
FLOW CONTROL (dl) (d3) #28 (d3) 
Note 2 
ERROR ERROR DISCARD 
(d3) (d3) (d3) 
#41 #41 
ERROR ERROR DISCARD 
(d3) (d3) (d3) 
THAN ONE OCTET OR IS NOT R27 #28 
SUPPORTED BY THE DCE 


INVALID PACKET TYPE ON A ERROR ERROR DISCARD 

PERMANENT VIRTUAL CIRCUIT Cd3) #35 Cd3) #35 Cd3) 

REJECT PACKET NOT SUBSCRIBED ERROR ERROR DISCARD 
Cd3) #37 Cd3) #37 Cd3) 


NORMAL: DCEs follow the procedures defined in §-4. For packets exceeding the 
maximum permitted length, DCEs invoke the error procedure using diagnostic code #39 
and enter state d3. 


RESTART REQUEST OR DTE RESTART 
CONFIRMATION WITH BITS 1 to 4 
OF OCTET 1 OR BITS 1 to 8 OF 

OCTET 2 # 0 


PACKETS HAVING A PACKET TYPE 
IDENTIFIER WHICH IS SHORTER 


DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. . 


ERROR: DCEs discard the received packet and indicate a reset by transmitting a 
RESET_INDICATION packet, with the cause "Local Procedure Error” (diagnostic per 
Table C-4). On virtual calls and permanent virtual circuits the remote DTE is 
informed of the reset by a RESET_INDICATION packet with the cause "Remote Procedure 
Error™ (same diagnostic). 


When a RESET_INDICATION is issued as a result of an error condition in state d2 for 
permanent virtual circuits, (text deleted) DCEs should eventually consider the 
DIE/DCE interface to be in the FLOW CONTROL READY state (d1). The action to be taken 
on virtual calls is for further study. 


Note: 
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1. 


There may be more than one error associated with a packet (e.g., Invalid Ps and. 
Invalid Pr). Networks stop processing of packets when an error is encountered. 
Thus, only one diagnostic code is associated with an error indication by DCEs. 
The order of packet de-coding and checking is not standardized among networks. 


DCEs consider the receipt of a DTE_INTERRUPT_CONFIRMATION packet which does not 
correspond to a yet unconfirmed DCE_INTERRUPT packet as an error and resets the 
virtual call or permanent virtual circuit (diagnostic #43). DCEs either discard 
or consider as an error a DTE_INTERRUPT packet received before a previous 
DTE_INTERRUPT packet has been confirmed (diagnostic #44). 


When Ps or Pr received is not valid, DCEs invoke the error procedure with 


diagnostics #1 and #2, respectively, and enter state d3. | 
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D.0 APPENDIX D: TIME-LIMITS AND TIME-OUTS 


Packet level DCE time-outs and DTE time-limits. 


D.1 DCE TIME-OUTS 


In 


certain circumstances DTEs are required to respond to packets issued from DCEs 


within a stated maximum time. 


Table JII-D-1 covers these circumstances and the actions that DCEs initiate upon 
expiration of that maximum time. 


| To 


facilitate recovery from such fault conditions, IBM SNA X.25 DTEs incorporate 


timers. Time-out values are indicated for DTE implementations in Table II-D-2. 


| Text deleted. 


T1ll 180 
secs. 


TE 


ion II-D-1: DCE TIME-OUTS 


a 
area) 28 Starts 
| No. [Value when 


DCE sends 
IRI pkt 


Actions taken when the aoe 
expires (see Note 


Local Side Remote Side 


DCE remains in r3 |For PVCs, DCE 
and may send a DGNlienters state d3 
packet. (Note 2) signalling RSI 
Cremote proce-— 
dure error) 


Normally 
Terminated 
when 


DCE leaves 
state r3 

Ci1.e., the 
TSC or IRR 
is rec'd) 


DCE sends 
an INC 


DCE leaves DCE enters state 
p7 signalling a 
CLI Clocal proce- 


dure error) 


DCE enters state 
p7 signalling a 

CLI Cremote proce 
dure error) 


DCE sends 
an RSI 


DCE leaves 
state d3 

(e.g., the 
TRC or RSR 
is rec'd) 


For VCs, DCE en- 
ters state p/7 

signalling CLI 

Clocal procedure 
error). For PVCs, 
DCE remains in d3 
and may send a DGN 
pkt (Note 3) 


For PVCs, DCE en- 
ters state p/7 
signalling CLI 
Cremote procedure 
error). For PVCs, 
DCE enters state 
d3 signalling RSI 
Cremote procedure 
error) 


T13 60 
secs. 
secs. 


DCE sends 
a CLI 


DCE leaves DCE remains in p7 
and may send a DGN 


packet. (Note 4) 


TSC or CRQ 
1s res'd). 


Notes with reference to Table II-D-l: 


1. 


The following Notes 2, 3 and 4 describe alternative DCE actions on timer 
expiration. It is envisaged that all networks will eventually conform to Table 
II-D-1, however, for an interim period the following procedures may be used. 


No values have yet been assigned to the time-out t and the maximum number of 
retries n applying to the following notes, however, it should be noted that some 
Administrations may use the combination t-infinite, n-zero Ci.e., no retries and 
no recovery action) or t-finite, n-zero Ci.e., no retries with recovery action on 
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timer expiration). The values of n and t will not necessarily be the same for the. 
clear, reset and restart procedures. 


Alternatively, DCEs may retransmit a RESTART INDICATION packet at regular 


intervals of ‘'t' until a DTE RESTART CONFIRMATION jis received or a restart 
collision occurs or a period ('nt1l')'t' elapses since the first transmission of 
the RESTART INDICATION. If the restart procedure is not completed within the 
time-out period, appropriate recovery action is taken. 


Alternatively, DCEs may transmit a RESET INDICATION packet at regular intervals of 
*t* until a DTE RESET CONFIRMATION is received or a reset collision occurs or a 
pertod C'ntl'")'t" elapses since the first transmission of the RESET INDICATION. 
If the reset procedure is not completed within the time-out period DCEs either: 


a. clear the virtual call with a procedure error indication; or, 


b. reset the permanent virtual circuit by transmitting a RESET INDICATION packet 
(remote procedure error) to the local DTE at regular intervals 't' until a DTE 
RESET CONFIRMATION is received or a reset collision occurs. 


Alternatively, DCEs may retransmit a CLEAR INDICATION at regular intervals of 't'* 
until a DTE CLEAR CONFIRMATION is received or a clear collision occurs or a period 
C' ntl? <<" elapses since the first retransmission of the CLEAR INDICATION. If the 
clear procedure is not completed within the time-out period, appropriate recovery 


-action is initiated. The nature of the recovery action is for further study. 
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D.2 DTE TIME-OUTS AND TIME-LIMITS 


In certain circumstances DCEs are required to respond to packets from DTEs within a 
stated maximum time. The actual DCE response times should be well within the 
specified time-limits. The rare situation where a time-limit is exceeded should only 
occur when there is a fault condition. 


To facilitate recovery from such fault conditions, IBM SNA X.25 DTEs incorporate 
timers. Time-out values for IBM SNA X.25 DTE implementations are indicated in Table 
II-D-2. 


| Text deleted. 


TABLE II-D-2: DTE TIME-OUTS and DCE TIME-LIMITS (see NOTE) 


DCE 
Time-Limit LC 
State Starts 
when 
180 r2 DTE sends 
secs. an IRR 
; =f 


T22 180 
Secs. 


Request pkts may be re- 
transmitted at 200 sec. 


Terminates 


intervals 'n20' times 
Normally after an initial time- 
when out. Following which, 


DTE leaves state r2 
the NSC or IRI 


the interface becomes 
inoperative and restart 
failure notification is 
given to a hAigher 

level. 


DTE sends 
a CRQ 


DTE leaves 
Ce.g., the CCN, CLI or 
INC pkt is rec'd) 


the logical channel be- 
comes inoperative and 
call failure notifica- 
tion is given to a 
higher level. 


DTE sends|DTE leaves state d2 
Ce.g., the NRC or RSI is 


rec'd) 


the logical channel be- 
comes inoperative and 
reset failure notifica— 
tion is given to a 
higher level. 


¥23 DTE leaves state p6 the logical channel be- 
Ce.g., the NCC or CLI is [comes inoperative and 
rec'd) clear failure notifica- 
1s received) tion is given to a 
higher level. 
Note: DTE time-outs are 200 seconds. 
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E.0 APPENDIX E: DCE DIAGNOSTICS 


Coding of X.25 network generated diagnostic fields in clear, reset and restart 
tndication and diagnostic packets. 


E.1 DIAGNOSTIC CODES 


TABLE E_1 DCE Diagnostics 


Decimal 


Oo 

wd 
ow 
ate 
ct 
ul 


—- ORMMOO]&~ OF RKP OO]H CFF OORKOORHOO]H OOFFOORPFrFOOrFRrFOO] eH FOO] NM 


(Notes 1, 2 and 3) 


No Additional Information 
Invalid Ps 
Invalid Pr 


Packet Type Invalid 
for state rl 
for state r2 
for state r3 
for state pl 
for state p2 
for state p3 
for state p4 
for state p5 
for state p6 
for state p/7 
for state dl 
for state d2 
for state 


MmmMmMmMMOODOQDQOQO!] F&F: G2OO!] & 


Packet Not Allowed 
unidentifiable packet 

call on one way logical channel 

invalid packet type on a PVC 

packet on unassigned logical channel 
REJECT not subscribed to 

packet too short 

packet too long 

invalid general format identifier 
restart with nonzero in bits 1-4,9-16 0 
packet type not compatible with facility 
unauthorized interrupt confirmation 
unauthorized interrupt 


Expired 
for INCOMING CALL 

for CLEAR INDICATION 
for RESET INDICATION 
RESTART INDICATION 


mmemmie | Os DODODDDODDDOOO | He RH HH HR Re Hee ere | Os OOO | UI 


oooooeo Pre Rime Me OOO qaaacee fut o 


oe Qoooeo 3S eooooeo oS (= oS eeao0acooooococ*#aaocaae i=) ooo 
-~ fn® fut fen fe Fe fom ] ooQaoeo Lo) oOaooooeo0ocoeaoaoaaooqa oS eSananaooaoaoeoraoo0e0oeo oa Lom } ooo 
i) Qeoeooqo -- fact fad fot ft fe ~ fat fet fmt fet ft fee fat ft ft fot fot ft oS eaocoroaoocoecooooooo f omw ] aeoao oO 
aad ROoaoane -— ~OoOo& Lad mM@OaQagodrKK HMR OOOO -~ Rm OOoaoeodrKKRrr Oooo — ooo Cl 
= O- OF -— Qe Oreo cad ore OF OF OF OFM OF SG h— ROOF OF OF OFM OF OFS oo oreo ~ 


1 1 63 

Call Setup Problem 0.6 COO 64 
facility code not allowed 0 60 65 
facility parameter not allowed 0 6«(—O 66 
invalid called address 06 (OO 67 
invalid calling address 0 60 68 

0 1 79 
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TABLE E_1 DCE Diagnostics — Continued 


Call clearing Sea | 
non-zero address lengths field 
non-zero facility length field 


Not Assigned 


Not Assigned 


Reserved for Network Specific Diagnostics 


Not all diagnostic codes need. apply to a anecitic network, but those used are as 
coded in Table E_l. 


A given diagnostic dd not apply to all packet types Ci.e., reset indication, 
clear indication, restart indication and diagnostic packets). | 


The first diagnostic in each grouping is a generic diagnostic and can be used in 
place of the more specific diagnostics within the grouping. The decimal '0' 
diagnostic code can be used in situations where no additional information is 
available. | 


(Text deleted). 
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.F.0 APPENDIX F: DTE DIAGNOSTICS 


Codes transferred in the diagnostic code field of CLEAR, RESET AND RESTART REQUEST 
packets generated IBM SNA X.25 DTEs on SNA-to-SNA connections convey the meaning 
indicated in Table F_l. 


F.1 DTE DIAGNOSTIC CODES ON SNA-TO-SNA CONNECTIONS 


TABLE F_1 DTE Diagnostics 


(Notes 1, 2 and 3) 


Normal Initialization or Termination 


Invalid LLC Type 


oe 


Invalid Packet Type (General) 
for State rl 
for State r2 
for State r3 
for State pl 
for State p2 
for State p3 
for State p4 
for State p5 
for State p6 
for State p7 
for State dl 
for State d2 
for ' State 


DCE Timer Expired (General) 
Incoming Call 
Clear Indication 
Reset Indication 
Restart Indication 


DQQDOO | mre et bt ht et ee pe te ee pee | Oe 


DTE Timer Expired (General) 
Call Request | ! 
Clear Request 
Reset Request 
Restart Request 


qQoo0oa her COOGEE =O 


bo fae et en ee | Co 


Unassigned (General) 


i] oO S eooooo fo | eooaoeoeo fo ] aeEaqoo0oocqc”eaqocooooo°oo i ] Lom] i— | 


eo-* & fut o 
ij—ro CO f=—2 ¢ 
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TABLE F_1 DTE Diagnostics — Continued 


Decimal 


Co | 
wo 
ant ¢ 

| et 
ju 


MOM Or OF OF OFM OF OF OC = hm © ead fo | ~ h— KH Or OF OF OF, S ad cad Or Oore Oro | RK OrF OF OF OF, © - 


QLLC Error (General) 
Undefined C-field 
wnexpected C-field. 

Missing I-field 

Undefined I-field 

I-field Too Long 

Frame Reject Received 

Header Invalid 

Data Received in Wrong State 

Time-out Condition 


PSH Error (General) 
Sequence Error 
Header too Short 
PSH Format Invalid. 

Command Undefined 

Protocol Invalid 

Data Received in Wrong State 


Time-out Condition 


PAD Error (General) 
PAD Access Facility Failure 
SDLC FCS Error 
SDLC Time-out 
SDLC Frame Invalid 
I-field too long 
SDLC Sequence Error 
SDLC Frame Aborted 
SDLC FRMR Received 

SDLC Response Invalid 


2s hth er eee | Oe Oo OOOQODOO !] Re HR Hee eee hee | UT 


Invalid Packet Type 
PAD Inoperable 


Product Specific 


Network Specific . 
DDX-P RNR Packet Received 


Packet Not Allowed (General) 
Invalid 'M' bit Packet Sequence 
Invalid Packet Type Received 
Invalid Packet on PVC 
Unassigned LC 

Diagnostic Packet Received 
Packet too short 

Packet too long 

Invalid GFI 

Not Identifiable 

Not Supported 

Invalid Ps 

Invalid Pr 

Invalid 'D* bit Received 
Invalid 'Q@* bit Received 


Paar a re ee ee ee — ee — ee — 2 2 a — ee — ee 

=i -h—-k—-k—-k—-k-—-—- — Pan a a a oe Oe ed ed el el el el 
fd fd pod dine iiiie 1 O OCO1O OClHF HH RRR RRR Rehm | ee RR Ree 1 Oo OOO OO OOOO | CO 
RP RHR eMORORDDOOCOO] FH: CGO] Rs O] Rs Re RROD OOOCOCO] Fr: Hs OAC OOCOO He HM HMOODDOQOOOO | a 
MMM mMODOOHMHME HOODOO ]H CO] Of] FF CORPRRFRFOOOCO]F OF FRrrOOOO |; Ff DOR FR HOADOO ! Ww 
MRHOOK MOOR HPOORHGAO!]H GCOl/rF OC]F HF DORPKFOORRFOO[ RF GF FPOOrRKOOS ~~ BDOrPrPOCOOrRFrOO !| 


eaoocvecoaqoanono0o0ndsndoo0ooa te fb lo ee — ]  ° 
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TABLE F_1 DTE Diagnostics — Continued 


Decimal 


fo] 

~ 
w 
ade 
ct 
ul 


b— foo ] KR OOF KR OOP KR OOF FOO anal eR OO - K OOr-r OOo _ foo om] N 


DTE Specific (NPSI Gate/Date) (General) 
No LU-to-LU Session 


176 
178 


191 


DTE Specific (General) 
Termination Pending 
Channel Inoperative 
Unauthorized Interrupt Confirmation 
Unauthorized Interrupt Request 
PU CPVC) Not Available 

Inactivity Time-Out 


oqgooo°oc*coo fate ft Ul 


Resources (General) 
Buffers depleted 
PIU too long 


Local Procedure Error (General) 
Packet with LC=0 not Received 

Restart or Diagnostic Packet on LCI#'O!® 
INCOMING CALL Received on Wrong LC 
Facility not Subscribed 

Packet Not RESTART or DIAG on LCI="'0! 
Facility Parameters not Supported 
Facility not Supported 

Unexpected Calling DTE 

Invalid 'D' bit Request 

RESET INDICATION on Virtual Call 
Invalid Protocol Identifier 

Connection Identifier Mismatch 

Missing Cause/Diagnostic Code 


- QEooo0°neaaqadooodoo & fee jf Oe 


Remote Procedure Error (General) 


= OO) FR RR RMPOOOOR FR HOQDOO!]eH C200] ”/ FPRRFROOOCO!]|H Foe] Ww 
mm aolKrorororKrororororale @oOrFa|R GrFOrFOrFO| RHR FO] FE 


tnt | ek feat feed fea fae fe feed fk fee fe fae ft ee pe ee | i | ee ee | et ie 
tet peak a pat fed fee fue fed fd ft fed fe fed pp pe | See | rh heer 1 OO OO 
mo tek | pk pt ft ee et repr iriritieieee | OO QOO!lO GCODQO0COC0O!] eH HRT A 
me CO] RRR Ree meMmMOOOOODOOCO!]FH- Qaaq0lr- GQQQ0COCOCO!|]rF- OQ] 


fmt o 


Note: 

1. All diagnostic codes are not necessarily used by all DTEs, but those that are used 
have the meaning indicated. 

2. The first diagnostic in each grouping is a generic code that may be used in place 
of the more specific codes within the group. 

3. These codes, set by transmitting DTEs, in CLEAR, RESET and RESTART packets are 


normally delivered to the remote DTE in a corresponding INDICATION packet by DCEs. 
However, DCEs may override DTE requests. In this event, DCEs place a non-zero 
Cause Code in the Cause field and insert the network Diagnostic Code (see Appendix 
E) in the Diagnostic Code field of the resulting INDICATION packet delivered to 
the remote DTE. 
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G.6 APPENDIX G: PACKET LEVEL DTE ACTIONS 


Actions taken by DTEs on receipt of packets in a given state of the DTE/DCE interface 
as perceived by the DTE. 


G.1_ DTE STATE/ACTION TABLES 


TABLE G_1 —- Special Situations . 


The characters after the "#* indicate the diagnostic code to be 
reported (See attachment F). 


DIAGNOSTIC Packet Received ADVISE #165 
(Note) 


Any packet with correct GFI on assigned LC See Table G_2 


ADVISE: DTEs discard the received packet and report the condition to a higher 
level using the indicated Diagnostic Code. No state transition takes place. 


DTEs discontinue normal packet processing when an error condition is encountered. 
Thus, only one diagnostic code is indicated for a single packet. The order in which 
packets are processed is not specified, therefore, a given packet containing 


multiple errors could result in different diagnostic indications when processed by 
different DTEs. 


Note: IBM SNA X.25 DTEs also report the contents of the Diagnostic Code and 
Explanation fields to a higher level. 
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TABLE G_2: Actions - taken by DTEs on receipt of packets’ in given | 
states of the packet level DTE/DCE interface as perceived 
by the DTE: Restart procedure for assigned LCs 


The codes in parentheses (In): speci fy the new states to be entered. 
The characters after the a indicate the ‘diagnostic code to be 


reported (see Attachment F). 
_ NORMAL 
(r3) 


Received Packet 


RESTART | 
INDICATION 


NORMAL 
(pl or dl) 
Note 


ADVISE 
C(r3) 
#36 


DCE RESTART CONFIRMATION | ERROR NORMAL ERROR | 
a Cr2) Cpl or dl) Cr2) 
#17 Note #19 


ANY PACKET on Logical Channel 
not equal to Zero 


Table DISCARD 
G_3 Cr2) 
Table ADVISE 

G_3 


Cr2) 
#226 
Table 
G_3 
Table 
G_3 


NORMAL: DTEs process the Keeeived packet in accordance with defined procedures. 


DCE RESTART CONFIRMATION or 
RESTART INDICATION on 
Logical Channel not equal to Zero 


PACKET ON Logical Channel Zero 
not RESET INDICATION, RESTART 
INDICATION or DIAGNOSTIC 


UNIDENTIFIABLE PACKET 


ADVISE 
Cr2) 
R169 


ADVISE 
(r2) 
#170 


UNSUPPORTED PACKET 


ADVISE: DTEs discard the received packet and report the condition to a higher 
level using the specified diagnostic code. No logical channel state transition 
occurs. 

ERROR: DTEs discard the received packet, report the error condition to a higher 
level and transmit a RESTART_REQUEST packet across the DTE/DCE interface placing all 
the logical channels in the DTE_RESTART_REQUEST state (r2). 


DISCARD: DTEs discard the received packet. No state transition takes place. 


Note: State 'pl for virtual calls or state dl for permanent virtual circuits. 


/ 
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TABLE G_3: DTE actions on receipt of packets in given states of the 
packet level DTE/DCE interface as perceived by the DTE: 
Call Set-up and Clearing on assigned Logical Channels. 


The codes in parentheses (ln) indicate the new state to be entered. 
The characters after the ‘'#' indicate the diagnostic codes to be 
reported (see Attachment F). 


PACKET LEVEL READY rl 


DATA CALL 
XFER COLL 

Packet 
Received p4 p5 


ERROR] ERROR] DISC ERROR 
(p3) (p6) (p6) (p6) (p6) 
Notes #23 #24 #26 
1, 2 1, 2 | 
ERROR|NORMAL] ERROR| ERROR|NORMAL] DISC 
(p6) (p4) (p6) (p6) (p4) (p6) 
#20 #22 #23 
NORMAL | NORMAL | NORMAL |] NORMAL | NORMAL | NORMAL | NORMAL 
(p7) Cp7) (p7) Cp7) (p7) Cpl) 
DCE CLEAR DISC ERROR; ERROR] ERROR{ ERROR|NORMAL] ERROR 
CONFIRMATION Cpl) Cp6) (p6) (p6) Cp6) (pl) (p6) 
R21 R22 #23 #24 #26 


OTHER PACKETS ERROR} ERROR| ERROR} TABLE;] ERROR} DISC 
(p6) Cp6) (p6) G_4 (p6) (p6) 
#20 #21 #22 #24 


NORMAL: DTEs process the received packet in accordance with defined procedures. 


ERROR: DTES report an error situation, using the indicated diagnostic code, and 
clear the virtual call or reset the permanent virtual circuit by transmitting a 
CLEAR/ZRESET REQUEST packet across the DTE/DCE interface. Some DTEs may optionally 
restart the DTE/DCE interface by transmitting a RESTART REQUEST packet. 


DISC: The packet is discarded. No state transition occurs. 


Note: 


1. For one-way outgoing logical channels, DTEs transmit CLEAR_REQUEST with the 
diagnostic code #227 on SNA-to-SNA connections. 


2. For packet format errors, DTEs transmit a RESTART_REQUEST with the diagnostic 
code #162 on: SNA-to-SNA connections. For unsubscribed facilities, DTEs transmit 
a CLEAR REQUEST with the diagnostic code #228 on SNA-to-SNA connections. 


DTES transmit a CLEAR REQUEST (on SNA-to-SNA connections, with the diagnostic 
code #208 if they cannot accept the call for some internal logical reason; and 
with diagnostic. code #12 if the calling DTE has indicated some unsupported 
end-to-end function (e.g., differing PSH support)). 
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TABLE G_4: DTE actions on receipt of packets in given States of the 
packet level DTE/DCE interface as perceived by the DTE: 
Data transfer, CInterrupt,] (Flow Control and Reset) on 
Assigned Logical Channels. : ) | a: on 


The codes in parentheses (ln) soeci ty the new states to be entered 
The characters after the '&' indicate the diagnostic codes to be 
reported Csee Attachment F). 7 ri 


FLOW 1 . DCE. 
CONTROL RESET 
Packet READY INDICATION 
Received Fo Al d3 : 
RESET INDICATION NORMAL NORMAL ADVISE 
(d3) (dl or p6) (d3) 
#45 
DCE RESET CONFIRMATION ERROR NORMAL 
| “eos Cdl or p6) 


DATA, CINTERRUPT,] and 
FLOW CONTROL 


DISCARD 
(d2) 


DISCARD 

(d2) 
See Attachment F for 
Diagnostic Codes 


INVALID PACKET TYPE, 
QLLC ERROR, PSH ERROR or 
PACKET NOT SUPPORTED 


NORMAL: DTEs process the received packet in accordance with defined procedures: 


ADVISE: DTEs discard the received packet and report the condition to a higher. 
level using the indicated diagnostic code. ; 


ERROR: DTEs discard the packet, report the error condition using the indicated 
diagnostic code and clear the virtual call or reset the permanent virtual circuit by 
transmitting a CLEAR/RESET_REQUEST packet across the DTE/DCE interface. 


Some DTEs may optionally restart the DTE/DCE interface by transmitting a 
RESTART_REQUEST packet. 


DISCARD: The packet is discarded. No logical channel state transition occurs. 
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H.0 APPENDIX H: PSH LOGICAL LINK CONTROL 


Logical Link Control (LLC) using Physical Services Headers (PSH) 


IBM SNA X.25 DTEs that communicate with remote IBM 5973 Network Titentaee Adapters 
CNIAs) use the Physical Services Header (PSH) to Peron the logical link control 
CLLCO) functions described in this appendix. 


H.1 PHYSICAL SERVICES HEADER FORMATS 


PSHs have the structure depicted in EugurS H-1. 


Octet |SNA Format Identifier (FID FOX) Ts Ts To 
1 PSC or SN or Data 
2 PSC or PSC Modifier (PSXID and PSTEST Information field as 
defined for SDLC XID and TEST, respectively) or Data 
3 
: PSC Modifier or Data 
nN : 
Legend: 
R —- Reserved cei: = Control Present Indicator 


(Control = PSC or PSC Modifier 
SI -—- Segmenting Indicator 


b'l' — More segments to b’'1' — Control Present 
follow b'0" — Control Not Present 
b'O0" — Last or only segment 
| PSC — Physical Services Command 
PSI —- Packet Sequence Indicator 
x'02" = PSDISC (CDISCONTACT) 
b'l* — Octet 1 = SN 
—- Octet 2 = PSC or Data x'04" = PSXID CEXCHANGE ID) 
b'Q" — Octet 1 = PSC or Data x'06" = PSTEST CTEST) 
x'O08* = PSCONTACT CCONTACT) 
~- Octet 2 = PSC Modifier 
or Data SN ~ Data Packet Sequence Number 


Note: Octet 2 of the PSCONTACT and PSTEST responses transmitted by a 
Secondary/Remote IBM 5973 NIA contains the SDLC station address. 


Figure H-1. Physical Services Header (PSH): Formats 


PSHs are inserted in front of SNA PIUs transmitted across the network(s), for: 


1. Adjacent SNA node physical services - traditional SNA functions such as XID, SNRM, 
and TEST that are mandatory for IBM SNA X.25 DTEs. Adjacent SNA node physical 
services are performed according to the same criteria as the equivalent normal 
response mode SDLC functions. 


2. Data Segmentation - permitting IBM SNA X.25 DTEs to segment user data into packets 
when the 'M' bit procedure is not used. 


3. sequence Numbering - an optional end-to-end packet sequence numbering function to 
provide for the detection of lost, duplicated or disordered data packets. 
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IBM SNA X.25 DTEs that must. remotely connect to an IBM 5973 Network Taterface Adapter 
(NIA) that support only PSH LLC must implement QLLC with 'M' bit segmenting/segment 
reassembly as well as PSH LLC. | | 


H.2 OPERATING RULES | 


Rules for use of Physical Services Headers on SNA-to-SNA connections, include: | 


4g 


The first octet of the Call User Data field in call control packets is coded with 
bits 8 through 1 = x'C2' or x'C6" to identify SNA-to-SNA connections that use 
PSHs. 


The PSH is used for segmentation. The "M* bit is not to be set equal to TL" by 
DITEs in data packets when the PSH is used for segmentation. 


The maximum User Data field length must be the same at both the local and remote 


DTE/DCE interfaces. 


Although either DTE may use the same PSH commands, the use of these is see Aedes, 
One DTE, designated '"F', may send PSXID, PSTEST or PSCONTACT at any time. The 
other DTE, designated TRY, must send PSXID, PSTEST or PSCONTACT only after having 
received the corresponding command. 


Either DTE may send PSDISC at any time. 


After sending PSXID, PSTEST or PSCONTACT, 'F' waits for a reply from 'R'. There is 
a timeout associated with this wait. | : 


If "°F" receives a PSXID, PSTEST or PSCONTACT command which is not in response toa 
corresponding command 'F* sends PSDISC or may terminate the virtual circuit by 
clearing, resetting or restarting. 


When either 'F' or 'R' receives a PSDISC it responds by sending a FSDISC command 
Cunless a PSDISC collision has occurred) or else terminates the virtual circuit. 


PSH LLC commands and responses are initiated by the same higher-level events that 
initiate their SDLC counterparts (see Figure 20 in §-8). 
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1.0 APPENDIX I: SNA-TO-NON SNA CONSIDERATIONS 


Architectural considerations for SNA-to-non_SNA connections 

Three implementations approaches are defined for SNA-to-non_SNA connections. In the 
first one, virtual circuit functions are mapped to an SNA session at the SNA boundary 
node permitting support of non_SNA nodes across packet-switched networks with limited 
effect on the subsystems. The second approach provides a transparent path between the 
X.25 DTE/DCE interface, residing in some SNA boundary node, and an application program 
interface which handles all the packets defined in CCITT Recommendation X.25. The 


third approach can provide various degrees of transparency and mapping for X.25 
virtual circuit functions. 


Y.1 IMPLEMENTATION APPROACH 1 


A Packet-Mode DTE implemented in an SNA PU.T4 or PU.TS5 node acts as a boundary function 
providing conversion between a virtual circuit and an SNA session. The non-SNA remote 
nodes may establish several virtual circuits across the network to/from the SNA 
PU.T¢/T5. To each of these virtual circuits, there corresponds a session acting aS a 
transportation mechanism towards some application interface in some SNA host node. 
The half session in the PU.T4/T5 will have the appearance of etther a SLU or a PLU, 
depending on the direction of call setting. This is to permit future extension to the 
SNA pass through function. 
The following mappings are possible: 
° INCOMING CALL packets may be mapped into either: 

1. Request Contact (with a pseudo ID); ors 


2. Unformatted INITSELF, carrying the contents of the call user data field and 
the calling DTE address to the USS of an SSCP that controls the PU.T4/T5. 


e +RESP/BIND is mapped into CALL ACCEPTED. 

® CONNOUT and BIND provide information to create CALL REQUEST. 

e CALL CONNECTED is mapped into +RESP/BIND. 

e CLEAR INDICATION is mapped into UNBIND. 

e UNBIND is mapped into CLEAR REQUEST. 

® RESET INDICATION is mapped into an extended SNA CLEAR. 

° SNA CLEAR extended is mapped into RESET REQUEST. 

° INTERRUPT is mapped into SIGNAL, and vice versa. 

° The data field of DATA packets are mapped into RUs. 

® Complete packet sequences need not necessarily be reassembled in the PU.T4/T5 
before transmission within SNA. Chaining can be used within SNA in order to 
relate unassembled PIUS which belong to the same packet sequence. 

° No direct mapping can be established between the X.25 window rotation mechanism 
for flow control and the SNA pacing mechanism. The PU.T4/T5 will act as an 
intermediate buffer and will handle flow control on each network as a function of 
its general memory assignment strategy by use of the appropriate mechanism on each 
side. 


® The 'D' bit is mapped to the form of RESPONSE REQUESTED bits in the RH, where: 


= "D'="'0" corresponding to the exception response indicator set to ‘1’. 
= "D'='1'4corresponding to the definite response indicator set to '1'. 


® Other higher level SNA functions - such as set and test sequence numbers, brackets 
and function management header protocols - are not mappable to X.25. 


APPENDIX I: SNA-TO-NON_SNA CONSIDERATIONS II-I-1 


SNA/X.25. DTE/DCE Interface 
T.2 IMPLEMENTATION APPROACH 2 


A. possible apehi tecture to permit transparent handling of X.25 is based on the 
provision of a single session path between the SNA boundary node and the application 
as depicted in Figure I-2. . 


All the virtual, circuits are multiplexed on this single session flow. Demultiplexing 
is performed, by analysis of the logical channel number in the packets, by the 


application. All of the functions of X.25, being thus handled transparently to SNA, 
can be supported in this environment. : 


I.3 IMPLEMENTATION APPROACH 3 


This hybrid approach is a mixture of approaches 1 and 2. Various degrees of X.25 
transparent and mapped function can be acheived on given SNA sessions. 
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Figure I-l1. VYirtual Circuit: Relationships to SNA Sessions 
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Figure I-2. One Session to Many Virtual Circuits: for SNA-to-non_SNA Connections 
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_ J.0 APPENDIX J: LINK LEVEL DTE ACTIONS 


Actions taken by DTEs for various link layer events in given Link Channel states of the 
Link Layer interface as perceived by the DIE 


Details on the operation of the Link Layer (Level 2) Balanced Link Access Procedure 
(CLAPB) protocols are given in the form of State/Action tables, in Tables J-l, -2, -3 
and -4. Actions to be taken by the DTE as a result of a particular stimulus are shown 
at the intersection of the various states of the Link Layer interface and the stimuli. 
Stimuli for the LAPB protocols include the events, commands and responses defined in 
TL APB Protocol Stimuli" on page II-J-3. The Link Layer states Cidentified by single 
lower case letters '(€s)' and the sub-states/options/conditions Cidentified by 
superscripts with the state designations '(s°,?,,,°%)') are described in "Link Layer 
Clevel 2) States." 


Information contained at these intersections show the actions to be taken Cindicated 
by two uppercase letters enclosed in parentheses 'CAA)'), the frame types to be sent 
Cif any» indicated by two uppercase letters 'FF’') and the new Link Layer states to be 
entered (Cif any, indicated by lower case letters enclosed in parentheses '(€s5)'). A 
note number reference '%n' is also included when further explanation is required. ° 


The frame type to be sent, 'FF', is any of the commands and responses depicted in Table 
II-3 of §-2.4.3. Supervisory frames (RR, RNR or REJ identified by RR, NR,» and RJ, 
respectively) are assumed to be responses unless otherwise indicated by‘the lower case 
letter ‘'c' following the frame type to be sent, '‘'FFce'; and the setting of the 
Poll/Final 'P/F' bit is indicated by '°' or '!" ('FF®,2)". No frame is transmitted 
when no frame type to be sent, "FF", is indicated. 


The new Link Layer state(s), (5s), indicates which of the defined Link Layer states is 
to be entered following transmission of the frame type to be sent, 'FF'. The Link 
Layer interface remains in the current state when no new Link Layer state to be 
entered, (5), is indicated. 


Alternative actions, frame types to be sent and new link layer states Cidentified by 
A, F or S, respectively, in the right most position of the STATES column) are shown for 
sub-states/options/conditions only when they differ from those shown for the base 
states. 


The various Link Layer states/sub-states/options/conditions and the 
en coerce ene raaen shown in Tables J-1, -2, -3, and -4 are summarized as 
follows: 


J.1 LINK LAYER (LEVEL 2) STATES 


DISCONNECTED State [DISCD - (a)] 


Link Seotiens assume the Link iavee DISCONNECTED state (a) (see § 2.4.5.4) when the 
Physical Layer initially becomes operational, after having received a DISC command and 
returned a UA response, after having received a UA response to a transmitted DISC 
command; or, optionally, after having detected the Idle Channel condition on the 
incoming link channel, if a flag sequence is not received within a specified period of 
time, Ti (see §§-2.2.12.2 and 2.4.11.5). 


LINK SET-UP State CSETUP - (b)] 
Link stations desiring to Cre)Jinitialize the link layer transmit a SET ASYNCHRONOUS 


BALANCED MODE CSABM) command and assume the Link Layer LINK SET-UP state (b) until an 


Fe ara sd UA or DM response is received from the remote link station (see 
-2.4.5.1) 


FRAME REJECTION State CFRJCN - (c)] 

Link stations having transmitted a FRMR response assume the Link Layer FRAME REJECTION 
state (c) until reset by the remote link station or until local recovery action is 
initiated (see §§-2.3.4.10, 2.3.5.6 and 2.4.10). 


DISCONNECT REQUESTED State EDCRQD - (d)]j 
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Link stations having transmitted a DISC command assume the Link Layer DISCONNECT 

Aaa state (Cd) to wait for a UA response from the remote link station (see 
-2.4.5.3). : 

INFORMATION TRANSFER State [LIFTRN - (a) ]j 

Link stations having received a UA response to a transmitted SABM command or having 
returned a UA response to an SABM command from the remote link station assume the Link 
Layer INFORMATION TRANSFER state (Ce) (see §-2.4.5.2). 

REJECTION State [CREJCN - (f)] 


Link stations having transmitted a REJ command/response requesting retransmission of 
an out-of-sequence frame(s) enter the Link Layer REJECTION state (f) (see §§-2.3.5.2, 
2.3.5.3 and 2.4.6.5). 


CHECKPOINT RECOVERY State [CPRCV - (q)] 
Link stations enter the Link Layer CHECKPOINT RECOVERY state (€g) upon expiration of 
Reply Timer, Tp, and transmit an appropriate Supervisory command.frame with 'P=1’' (see 
§§-2,3.5.4 and 2.4.6.8). 

CHECKPOINT RECOVERY/REJECTION State [CPRRJ - (h)] 


The CHECKPOINT RECOVERY/REJECTION state (h) is a composite of the CHECKPOINT RECOVERY 
state (g) and the REJECTION state (f). 


LOCAL STATION BUSY State [LBUSY - (i) J 
Link stations. having transmitted an RNR command/response, jadicatine their inability | 
to handle additional information. frames due to some internal constraint (i.e., buffer 


eo assume the Link Layer LOCAL STATION BUSY state (i) (see §§-2.3..5.1 and 
2.4.6.7). 


REMOTE STATION BUSY State [RBUSY - (j)] 


Link stations enter the Link Layer REMOTE STATION BUSY state (j) upon receipt of an RNR 
command/response from the remote link station (see §§-2.3.5.1 and 2.4.6.7). 


BOTH STATIONS BUSY State [BBUSY - (k)] 

Link stations enter the Link Layer BOTH STATIONS BUSY state (k) upon receipt of an RNR 
command/response from the remote link station while in the Link Layer LOCAL STATION 
BUSY state (i); or, after transmitting an RNR command/response while in the Link Layer 
REMOTE STATION BUSY state (j) (€see §§-2.3.5.1 and 2.4.6.7). 

REJECTION/LOCAL STATION BUSY [RJNLB - (1)] 


This state (1) is a composite of the Link Layer REJECTION state (€f) and the Link Layer 
LOCAL STATION BUSY state (i) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


REJECTION/REMOTE STATION BUSY CRJNRB - (m)] 


This state (m) is a composite of the Link Layer REJECTION state (f) and the Link Layer 
REMOTE STATION BUSY state (j) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


REJECTION/BOTH STATIONS BUSY ECRJNBR - (n)] 


This state (€n) is a composite of the Link Layer REJECTION state (f) and the Link Layer 
BOTH STATION BUSY state (k) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


CHECKPOINT RECOVERY/LOCAL STATION BUSY ECCPRLB - (0)] 


This state €0) is a composite of the Link Layer CHECKPOINT RECOVERY state (g) and the 
Link Layer LOCAL STATION BUSY state (i) (see §§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 


CHECKPOINT RECOVERY/REMOTE STATION BUSY CCPRRB - (p)] 


This state (p) is a composite of the Link Layer CHECKPOINT RECOVERY state (g) and the 
Link Layer REMOTE STATION BUSY state (j) (see $§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 


CHECKPOINT RECOVERY/BOTH STATIONS BUSY CCPRBB - (q)] 
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Thi. state €q) is a composite of the Link Layer CHECKPOINT RECOVERY state (g) and the 
Link Layer BOTH STATIONS BUSY state (k) (see §§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 
CHECKPOINT RECOVERY/REJECTION/LOCAL STATION BUSY [CRJLB - (r)J 


This state (r) is a composite of the Link Layer CHECKPOINT RECOVERY state (9), the Link 
Layer REJECTION state (f) and the Link Layer LOCAL STATION BUSY state (i). 


CHECKPOINT RECOVERY/REJECTION/REMOTE STATION BUSY [CRJRB - (s)] 


This state (s) is a composite of the Link Layer CHECKPOINT RECOVERY state (g), the Link 
Layer REJECTION state (f) and the Link Layer REMOTE STATION BUSY state (j). 


CHECKPOINT RECOVERY/REJECTION/BOTH STATIONS BUSY CCRJBB - C(t) 


This state (t) is a composite of the Link Layer CHECKPOINT RECOVERY state (gg), the Link 
Layer REJECTION state (f) and the Link Layer BOTH STATIONS BUSY state (k). 


INOPERATIVE ENOPTV - (u)] 


The Link Layer assumes the Link Layer INOPERATIVE state (u) when the Physical Layer is 
not operational (see §-2.4.5.1). 


SUB-STATES/OPTIONS/CONDITIONS 
Sub-states/Options/Conditions applicable to the various Link Layer states include: 


° - Alternatives that may be implemented in lieu of the architecturally preferred 
procedure. 


1 - When at a convenient respond opportunity. 
¢ - When a response to a command received with "P=1" is required. 
+ - When a response is not appropriate, if desired. 


4 - When no I-frame is available for transmission or when the link level transmit 
window is full Ce.g., the number of unacknowledged I-frames is equal to 'K'). 


5S - When not prepared to continue operation with, or following, 
Credinitialization of the Link Layer interface. 


© - When enabled and prepared to (CredJinitialize the link layer interface and 
support the transfer of information. 


7 - When not at a convenient respond opportunity and no I-frames have been 
discarded. 


6 - When at a convenient respond opportunity and one or more I-frames have been 
discarded. 


9 - When not at a convenient respond opportunity and one or more I-frames have 
been discarded. 


J.2  LAPB PROTOCOL STIMULI 


Stimuli for the LAPB protocol include the events, commands and responses described in 
the “Events,” "Commands" on page II-J-4 and "Responses" on page II-J-6, respectively. 


J.2.1 Events 


PlLopt (Physical Layer Operational) 


The Physical Layer Operational (PLopt) event represents a transition of the Physical 
Layer Clevel 1) to the operational state (see §-2.4.5.1) 


Lstrt CLink Start) 
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The Link Start (Lstrt) event represents instruction from a higher layer to. set- up 
Cinitialize/restart) the Link Layer interface (see §-2.4.5.1). 


Lstop (Link Stop) 


The Link Stop (Lstop) event represents instruction from a higher layer to terminate | 
Link Layer operation (see §-2.4.5.3). 


PLnop (Physical Layer Inoperative) 


The Physical Layer Inoperative (PLnop) event vepnawents a transition of the Physical 
Layer (level 1) to the inoperative state (see §-2.4.5.1). 


Ebusy Cloce:] Station Entering Busy Condition) 
The Local Station Busy (Ebusy) event occurs when the local station can not accept 


additional I-frames because of some internal constraint (e.g., buffering limitations, 
see §-2.4.6.7) 


Lbusy (Local Station Exiting Busy Condition) 


The Local Station Exiting Busy (Lbusy) event occurs when a local station recovers from 
a busy condition (see §-2.4.6.7). 


TpExp (Timer Tp Expiration) 


Maes Timer Tp Expiration CTpExp) event occurs upon expiration of Reply Timer, Tp (see 
-2.4.11.1) 


TnExp (Query Timer Tn Expiration) 
The Query Timer Tn Expiration (TnExp) event occurs following a period of link 


aba ee lasting for the duration of Query Timer, Tn (see §§-2.3.4.4, 2.4.6.6 and 
2.4.11.1). 


FtExp (Nested Time-out Expiration) 


This Nested Time-out Expiration event CFtExp) occurs when the maximum number of 
repetitions (Nd) is exhausted (see §-2.4.11.1). 


TlFrm (Illegal Frame) 

The Illegal Frame (IlFrm) event represents the correct receipt of a frame containing a 
command/response that is invalid or not implemented, an information field that exceeds 
the maximum permissible length, an invalid Wr, an information field that is not 
permitted, or an S or U frame of incorrect length (see §§-2.3.4.10 and 2.3.5.6). 

InFrm CInvalid Frame) 

The Invalid Frame (InFrm) event represents the receipt of a frame not properly bounded 
by two flags, having fewer than 32 bits between flags (see §-2.2.9) or one containing 
an address other than 'A' or 'B’ (see §-2.4.2). 

RLchi (Receive Link Channel Idle) 

The Receive Link Channel Idle (RLchi) event occurs following detection of the idle 


condition if a flag sequence is not received within the Idle Time-out period, Ti (see 
§§-2.2.12.2 and 2.4.11.5). 


TLeohr (Transmit Link Channel Ready) 


The Transmit Link Channel Ready C(TLchr) event occurs. following transmission of the 
last bit of the current frame. 


J.2.2 Commands 
DC° (Disconnect with 'P=0"') 


coe ee a DISCONNECT CDISC) command frame with the poll (P) bit set to zero (see 
“2.3.4.7). : | 
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DC? (Disconnect with "P=1") 


eee a DISCONNECT CDISC)} command frame with the poll (P) bit set to one (see 
=2.35.4.7) 5 


IR° (Requested Information Frame with 'P=0") 


Represents the requested information command frame with the poll (P) bit set to zero 
(see §-2.4.6.5). 


IR? (Requested Information Frame with '"P=1") 


Represents the requested information command frame with the poll (P) bit set to one 
(see §-2.4.6.5). 


IS° (In-Sequence Information Frame with 'P=0"') 


Represents the next in-sequence information (I) command frame with the poll (CP) bit 
set to zero, if available, (see §-2.4%4.6.2) otherwise continuous flag sequences. 


IS? (In-Sequence Information Frame with 'P=1") 


Represents the next in-sequence information (CI) command frame with the poll (P) bit 
set to one, if available, (see §-2.4.6.2) otherwise continuous flag sequences. 


NR° (Receive Not Ready with 'P=0") 


Represents a RECEIVE NOT READY CRNR) command frame with the poll (P) bit set to zero 
(see §-2.3.4.4). 


NR! (Receive Not Ready with "P=1") 


Represents a RECEIVE NOT READY (RNR) command frame with the poll (CP) bit set to one 
(see §-2.3.4.4). 


RR® (Receive Ready with '"P=0") 


aaah a Receive Ready (RR) command frame with the poll (P) bit set to zero (see 
~2.3.4.2). 


RR! (Receive Ready with "P=1") 


ae a Receive Ready (RR) command frame with the poll (P) bit set to one (see 
-2.3.4.2). 


RJ° (Reject with "P=0") 


eooee ee. a REJECT CREJ) command frame with the poll (P) bit set to zero (see 
-2.3.4.3). 


RJ? (Reject with "P=1") 


Baers a REJECT (CREJ) command frame with the poll (P) bit set to one (see 
=243:. 46372 


SE° (Out-of-Sequence Information Frame with "P=0') 


Represents an out-of-sequence information command frame with the poll (P) bit set to 
zero (see §§-2.3.5.2 and 2.4.6.2). 


SE! (Out-of-Sequence Information Frame with 'P=1") 


Represents an out-of—sequence information command frame with the poll CP) bit set to 
one (see §§-2.3.5.2 and 2.4.6.2). 


SM°_ (Set Asynchronous Balanced Mode with 'P=0"') 


Represents a SET ASYNCHRONOUS BALANCED MODE CSABM) command frame with the poll (P) bit 
set to zero (see §-2.3.4.6). 


SM! (Set Asynchronous Balanced Mode with 'P=1") 


Represents a SET ASYNCHRONOUS BALANCED MODE CSABM) command frame with the poll (P) bit: 
set:to one (see §-2.3.4.6). 
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| Note: Commands followed by ‘ak’ (LL°,2ak) indicate a received frame containing an 
ha aca opad ald Can Nr greater than the last Nr received) for previously transmitted 
I-frame(s 


J.2.3 Responses 


CF (Continuous Flags) 
Represents continuous flag sequences (see §§-2.2.11 and 2.4.5.1). 
DM_ (Disconnected Mode with 'F=0 or 1") 


Represents a DISCONNECTED MODE (CDM) response frame with the final (F) bit set to 
either zero or one (see §-2.3.4.9). 


FR (Frame Reject with "F=0 or 1°) 


Represents a FRAME REJECT CFRMR) response frame with the final (F) bit set to either 
zero or one (see §-2.3.4.10). 


NR° (Receive Not Ready with 'F=0") 


Represents a RECEIVE NOT READY (RNR) response frame with the final (F) bit set to zero 
(see §-2.3.4.4). 


NR? (Receive Not Ready with "F=1') 


Represents a RECEIVE NOT READY CRNR) response frame with the final CF) bit set to one 
| Csee §-2.3.4.4). 


RJ° (Reject with 'F=0") 


coon ss a REJECT CREJ) response frame with the final (CF) bit set to zero (see 
-2.3.4.3). 


RJ? (Reject with "F=1") 


eo ae a REJECT (CREJ) response frame with the final (F) bit set to one (see 
-2.3.4.3). | 


RR° (Receive Ready with 'F=0") 


Sopa 55 a RECEIVE READY CRR) response frame with the final (CF) bit set to zero (see 
-2.3.4.2). 


RR! (Receive Ready with "F=1"') 


oe a RECEIVE READY CRR) response frame with the final (CF) bit set to one (see 
-2.3.4.2). 


UA CUnnumbered Acknowledgement with 'F=0 or 1") 


Represents an UNNUMBERED ACKNOWLEDGEMENT (UA) response frame with the final (F) bit 
set to either zero or one (see §-2.3.4.8). 


Note: Responses followed by ‘ak’ (LL°,*ak) indicate a received frame containing an 


acknowledgement (Can. Nr greater than the last Nr received) for previously transmitted 
I-frame(s). 


J.3 ACTIONS 


(AA) Advance Transmit Window and Acknowledge Receipt 
Advance the lower transmit window edge to the Nr contained in the received frame, 


acknowledge receipt (Cincrement Vr by ‘'1') of the received frame and pass the 
information field to a higher layer (see §§-2.4.6.2, 2.4.6.4 and 2.4.6.8). 
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(AD) Advance Transmit Window and Discard Frame 


Advance the lower transmit window edge to the Nr contained in the received frame and 
discard the information field (see §§-2.4.6.2.2 and 2.4.6.4). 


CAF) Acknowledge Receipt and Forward I-field 


Acknowledge receipt (increment Vr by "1") of the received frame and pass the 
information field to a higher layer (see §-2.4.6.2.1) 


(AL) Assure Link 


Assure link operation by transmitting a command frame with "P=1'" and starting reply 
timer, Tp (see §§-2.4.3 and 2.4.6.8). 


(AR) Advance Transmit Window and- Resume Transmission 
Advance the lower transmit window edge to the Nr contained in the received frame and 


i aT ea transmission of information frames (seeS$- 2.4.6.4, 2.4.6.6 and 
2.%.6.7). 


(AS) Advance Transmit Window and Suspend Transmission 


Advance the lower transmit window edge to the Nr contained in the received frame and 
suspend sequential transmission of information frames (see §§-2.4.6.4 and 2.4.6.6). 


(AW) Advance Transmit Window 


sce ee lower transmit window edge to the Nr contained in the received frame (see 
-2.4.6.4). 


(AX) Advance Transmit Window and Set Send Sequence 

Advance the lower transmit window edge to the Nr contained in the received frame and 
set the send sequence variable (Vs) equal to the value of Nr contained in the received 
frame (see §§-2.4.6.4 and 2.4.6.5). 

(DF) Discard Frame 


Discard the information field contained in the received frame (see §§-2.4.6.3 and 
2.4.6.7). 


(DL) Disconnect Link 

Initiate the link disconnection procedure described in §-2.4.5.3. 
CIC) Increment Count 

Increment the retransmission count (see §-2.4.11.2). 

(1F) Ignore Frame 

Igneve the received frame (see §§-2.2.9, 2.3.5.5 and 2.4.2). 

(TH) Inform Higher Layer Protocols 


Higher layer protocols may be informed of the event/condition/state using DTE specific 
internal signalling mechanisms (see §§-2.4.3.1, 2.4.5.1, and 2.4.5.3). 


CTL) Initialize Link 
Set-up Cinitialize) the link in accordance with the procedures described in §-2.4.5.1. 
(LE) Logical Local Error 


Logically erroneous local conditions may be reported to higher layer protocols and the 
current state maintained pending further instructions. 


(PC) Product Criteria 


Retransmit the FRMR response until recovery based on local product criteria is 
initiated. | : 


(NS) No Specific Action 
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No specific local DTE action required. 


(RE) Remote Procedure Error 


Logically erroneous remote conditions may be reported to higher layer protocols and 
the current state maintained pending further instructions. 


(RL) Reset Link 

Reset Cre-initialize) the link in accordance with the procedures described in §-2.4.9. 
CRT) Resume Transmission 

Resume sequential transmission of information frames (see §§-2.4.6.2.1 and 2.4.6.7). 
(SR) Set Send Sequence and Resume Transmission 

Set the send sequence variable (Vs) equal to the value of Nr contained in oo received 


frame is resume sequential transmission of information frames (see §§-2.4.6.5 and 
2.4.6.7 


($5) Set Send Sequence 


Set the send sequence variable (Vs) equal to the value of Nr contained in the received 
frame (see §-2.4.6.4). 


2 CST) Suspend Transmission 

Suspend sequential transmission of information frames (see §-2.4.6.6). 

CTR) Time Reply 

Start reply timer, Tp, if it is not already running (see §-2.4.11). 

(XR) Advance Window, Set Send Sequence and Resume Transmission 

Advance lower transmit window edge, set the send sequence variable (Vs) equal to the 


value of Nr contained in the received frame and resume sequential transmission of 
information frames Csee §§-2.4.6.4 and 2.4.6.5). 
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Table II-J-1: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 


CLE) JCLE) (CLE) | CIH) (LE) 
- - |#3 - /#4 - = 


(TR) 
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Table II-J-la: Actions taken as a result of Events occurring in various states. 


of the Link Layer Interface as perceived by OTEs 


EVENTS 
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Table II-J-lb: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 


states [top 
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Table II-J-le: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 


EVENTS 
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Table II-J-2: Actions taken as a result of Information 
Command Frames received in various states of 


the Link Layer Interface as perceived by 


COMMANDS 
srares [5° fhe] oot ist] se [ora] oe ae 


(DF) |CAD) 
er Ryt 
1820 #) 


(AD) | CDF) 
RJ Ry? 
R2Ch) 1 Ch) 


(AA) | CAF) 
RR RR? | 
R2(g) (g) 


(DF) ee sae (AD) 
ie Ry! 
slo YIF2(m) 
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Table II-J-2a: Actions taken as a result of Information 
Command Frames received in various states 
of the Link Layer Interface as perceived 


COMMAND 


sires [7 ae 
BBUSY (AD) 
| NR 
| w2 - 
1 JRINLB (AD) 
: NR 
#207) 
RJNRB (AA) 
RR | 
#25) 
RJNBB |(OF) |(AD) [CDF) | aD) (AD) (AD) 
NR NR NR? | NR} NR NR} 
CkK)[R2CK)] CK) R2CKk #2 — #2 = 
CPRLB (AD) |CDF) |caAD) (AD) (AD) 
NR NR? | NR? NR NR? 
#2 — - {#2 - t2 - %2 — 
CPRRB (AA) (AA) JCDF) }CAD) TCDF) TCAD) 
RR RR? | RJ RJ RJ? | RJ 
#2 — #2 - (s)/#2e(s)] (s)/82Cs) 
CPRBB (AD) (AD) | (AD) (AD) 
| NR NRi NR KRi 
| #2 — #2 —- #2 — #2 - 
Ir |CRJLB (AD) (AD) (AD) (AD) 
| NR NR? NR NR 
| %2 — #2 - #2 — #2 — 
Is |CRJRB | CAF) | CAA) (DF) (AD) 
| RR RR RR RR} 
! (p)|#2(p) ~ #2 —- 
CRJBB (AW) (DF) | 
NR NR 
#20q) ~ 
fT. (LE) |CLE) TCLE) JCLE) TCLE) y Tene) [ered 
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Table II-J-3: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


sores [at oa] wat [tn] a aR] [ater] we ean] wt [een] om [oe [oe [oe 


(ST) |CAS) 
RR? | RR? 
(p) 12 Cp) 
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Table II-J-3a: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


COMMAND 
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Table II-J-3b: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


COMMAND 


i = = ici 


STATES 
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Table II-J-3c: Actions taken. as a result of Supervisory and Unnumbered Command Frames. received. in 
various states of the Link Layer Interface as perrelved by DTEs 


sa sail 


rene 


(LE) |CLE) JC LE) | CLE) ne el 


~ 


dua (Le) }(LED 
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Table II-J-4: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as perceived by DTEs 


RESPONSE 


saves [ae foean] owt Feta] oot ea] oF ota] wt Pata] we Pata] om [owt [oe 


SETUP (IH 
CIF. 
FRJCN (IH 
: CIF 
DCRQD (IH 
Al CIF. 

S| 

1 


[h CPRRJ (RT) | CAR) (AX) | CSS) | CAX) 
| IS IS IR IR IR 
(fF) (#20 F) #2 = Cf) #20 F) 
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Table II-J-Ga: Actions taken as a result of Response Frames received InN various ‘states of the 
Link Layer Interface as perceived by DTEs | _—_, 


RESPONSE 


RJNBB [(RT) | CAR) [CRT) ee (SR) |CXR) |CSR) | CXR) 
Is IS IR IR IR IR 
F201) (1) $200) C1)7;#201) CL] #201) 
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Table II-J-4b: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as perceived by DTEs 


RESPONSE 


(SR) 
IR 
(1) 
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Table II-J-Ge: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as. perceived by DTEs 


in NOPTV es 


Note 1 - Detection of the Idle Channel condition may be either ignored; or, if a flag 
sequence is not received within a period of time (Ti), considered as an event 
causing a change to the DISCONNECTED state (a) (see § 2.2.12.2). 


Note 2 - Upon correct receipt of a frame (containing an Nr that is higher than the last 
Nr received) acknowledging some previously transmitted I-frame(s), DTEs reset 
(stop) Reply Timer Tp and if additional unacknowledged I-frame(s) are still 
outstanding they restart Reply Timer Tp. 


Note 3 - Expirations of the Nested Time-out Function (Ft) are reported to a higher 
layer and the current state(s) of the Link Layer Interface maintained pending 
instructions from the higher layer. 


Note 4 - Illegal frames received are reported toa higher layer and the current 
state(s) of the Link Layer Interface maintained pending instructions from the 
higher layer. (FRMR?) 


Note 5 - To maintain DTE control, the 3705/X.25 NPSI transmits a SABM command with 
‘P=1', creating a collision of like commands, and then transmits a UA response 
to the received SABM command. 


>Note 6 - DTEs not prepared to continue/resume normal link level operation transmit a 
UA response followed by a DISC command and enter the Disconnect Requested 
(DCRQD) state. 


APPENDIX J: LINK LEVEL DTE ACTIONS II-J-22 


LINK LAYER 


CAA) 
CAD) 
CAF) 
CAL) 
CAR) 
CAS) 
CAW) 
CAX) 
(DF) 
CDL) 
CIC) 
CIF) 
(IH) 
CIL) 
CLE) 
(NS) 
CRE) 
CRL) 
CRT) 
CSR) 
(SS) 
(ST) 
CTR) 
(XR) 
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ACTION CODE REFERENCE SUMMARY 

Advance Transmit Window, Acknowledge Receipt and 
Advance Transmit Window and Discard Frame 
Acknowledge Receipt and Forward 

Assure Link 

Advance Transmit Window and Resume Transmission 
Advance Transmit Window and Suspend Transmission 
Advance Transmit Window 

Advance Transmit Window and Set Send Sequence 
Discard Frame 

Disconnect Link 

Increment Count 

Ignore Frame 

Report Status/Condition 

Initialize Link 

Local Procedure Error 

No Specific Action 

Remote Procedure Error 

Reset Link Level 

Resume Transmission 

Set Send Sequence and Resume Transmission 

Set Send Sequence 

Suspend Transmission 


Time Reply 
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Forward 


Advance Transmit Window, Set Send Sequence and Resume Transmission 
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K.0 APPENDIX K: ENHANCED LOGICAL LINK CONTROL —~ ELLC 


The formats and protocols described in this appendix are adaptations of Asynchronous 
Balanced Mode CABM) formats defined for HDLC and the X.25 Link Access Procedure - 
Balanced CLAPB) elements of procedure expanded to include an adaptation of the 
checksum data integrity mechanism defined in I5-8073 (Open Systems Interconnection 
Transport Protocol Specification -— ISO/TC-97/S5SC-6-N3240) dated September 1984. 


K.1 FUNCTIONAL OVERVIEW 


K.1.1 Architecture 


Architecture to meet SNA quality of service requirements in packet-switched data 
network environments: 


1. extends the Protocol Identifier defined for QLLC, in chapter 8.0, to allow 


Shara oad of the ELLC protocol, at call set-up time, as an alternative to QLLC or 


2. definition of a Connection_Type_Indicator (CTI) field within the Call_User_Data 
field of X.25 CALL_REQUEST packets to distinguish between inittal connection 
requests and connection recovery requests for ELLC; 


3. use of the Connection_Identifier (CID) field in Call Set-up packets to carry 
Link_Connection_Identification information between adjacent link stations; 


4. definition of LPDU headers that include: 
e a two-byte address field; 
e an extended (two-byte) control field; 
¢ a two-byte checksum field; and, 


° the use of LPDU headers in the User_Data field of X.25 DATA packets and DATA 
packet sequences to perform sequenced transfer of BTUs between link stations 
in adjacent SNA nodes. 


5. the definition of recoverable call clearing, virtual circuit resetting and 
interface restarting cause codes together with link connection recovery 
procedures. 


K.1.2 Link Connection Service 


With a one-for-one correspondence between DLC.X25 link connections and X.25 virtual 
circuits, link connection services required for logical link control, to meet quality 
of service enhancement objectives in PSDN environments, are provided by adaptation of 
existing X.25 Packet Level call set-up and clearing procedures. 


K.1.3 Link Connection Identification 


Since a one-for-one correspondence exists between X.25 logical channels and LLC link 
stations, X.25 logical channel identifiers can be used by LLC to route DATA packets to 
the appropriate link station. DLC.X25 link connection identification requirements are 
satisfied by correlating X.25 Calling DTE Address, concatenated with a Connection 
Identifier carried in CALL REQUEST packets when parallel virtual calls are employed 
between DTEs, with X.25 logical channel identifiers. 
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K.1.3.1 Permanent Virtual Circuit Services . 


The relationship between DLC.X25 link connections employing permanent virtual 
circuits and X.25 logical channel identifiers are fixed by bilateral agreement between 
communicating link stations; therefore, X.25 logical channel identifiers can suffice 
for both LLC routing and error recovery functions, in this environment. 


K.1.3.2 Switched Virtual Circuit ( Virtual Call ) Services 


Since X.25 logical channel identifiers for switched virtual circuits are dynamically 
assigned at call set-up time, they suffice only for the LLC routing function; and, are 
correlated to the X.25 Calling DTE Address, concatenated with the Connection 
Identifier as required, for use in error” situations requiring re-connection 
procedures. 


K.1.% Error Detection and Recovery. 


LLC error detection and recovery requirements are satisfied by ELLC which, when 
selected, provides mechanisms to detect, and procedures to attempt recovery from, the 
loss, duplication and/or corruption of LPDUs by underlying network services. ELLC 
incorporates sequence pumpering and welreuey cneeKing mechanisms, as well as circuit 
assurance procedures... 


K.1.4.1 Sequence Numbering 


ELLC formats and protocols provide for the sequenced (modulo 128) transfer of 
information LPDUs, together with LPDU acknowledgment and retransmission recovery 
procedures to guard against the loss or duplication of LPDUs, or both. 


K.1.4.2 Validity Checking 


ELLC also employs a checksum mechanism to detect LPDUs that have been corrupted by 
underlying network services and to insure the integrity of BTUs delivered to higher 
level using protocols. 


K.1.4.3 Circuit Assurance | 


ELLC circuit assurance capability defines recoverable error conditions reported by 
PSDNs through CLEAR, RESET and RESTART packets, as well as procedures for ascertaining 
and performing actual circuit recoverability. 


K.2 SCOPE AND FIELD OF APPLICATION 


The Logical Link Control (LLC) procedure is described as the element used to enhance 
the quality of service exhibited to higher level SNA users by the underlying network 
services in supporting the transfer of information between adjacent SNA nodes in PSDN 
environments. 


The procedure uses the principles and terminology of the High Level Data Link Control 
eane procedures specified by the International Organization for Standardization 


The transmission facility is duplex. 
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Compatibility of operation with the ISO balanced class of procedure (Class BA, options 
1, 2, 8 and 12) 3s achieved using the provisions found in this specification. 


K,3 LINK PROTOCOL DATA UNIT STRUCTURE 


All transfers across ELLC link connections are in LLC Protocol Data Units (LPDUs) 
conforming to one of the formats shown in Figure K-1 and contained in the User Data 
fieid of X.25 DATA packets or DATA packet sequences. | 


1 2 3 4 


A c X Y 
16—-bits 16—-bits 2 Octets* 


Supervisory and Unnumbered Format 


| 3 4 


2 5 6 


A C X Y I 
16—-bits 16—bits 2 Octets* N-Octets* 


Information Format 


PDUCS = Protocol Data Unit Checking Sequence —- (Checksum) 
¥ an Octet is an 8-bit byte. 


Figure K-1. LPDU Formats: Supervisory and Unnumbered versus Information 


K.3.1 Address ( A_) Field 


The LPDU address is a two-octet (16-bit) field which has the format shown in Figure 
K-2. The A field is positioned as shown in Figure K-1l1 and coded as described in 
"Procedure for Addressing" on page II-K-13. | | 


| Octet 1 l Octet 2 | 


where: | 
ADDRESS - is reserved and set to zeroes; and 


1s the LPDU command/response (C/R) indicator which is set to: 
"0" in command LPDUs; and, 
‘1’ in response LPDUs. 


Figure K-2. LPDU: Address Field Format 


x = 


K.3.2 Control ( C_) Field 


The C field is two octets positioned as shown in Figure K-1. whose content is described 
in "LPDU Formats and State Variables" on page II-K-5. | 
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K.3.3 Information ( I }) Field 
The I-field of LPDUs transmitted and received by link stations contain an SNA Path 


Information Unit (PIU) consisting of an integral number of octets (8-bit bytes). 


Note: LPDUs containing other than an integral number of octets ay be ignored at the 
physical or link level. 


See "LLC_Protocol_Data_Unit_Reject ( LPDUR ) Response” on page II-K-9 and "List of LLC 
Parameters" on page II-K-20 with regard to the maximum information field length. 


wd 


K.3.% Protocol Data Unit Checking Sequence ( Pnucs ) Field 


The PDUCS field is two octets positioned as shown in Figure K-1 whose content is 
described in "Protocol _Data_Unit_Checking_Sequence ¢€ PDUCS )" on page II-K-11. 


K.3.5 Order of Transmission 


Address, control, sequence number, Protocol Data Unit Checking Sequence (PDUCS) and 
information octets are transmitted in ascending octet number order as indicated in 
Figure K-1l low order bit first. 


K.3.6 Invalid LPDUsS 


LPDUs having fewer than forty-eight bits (€ six octets ) are invalid. 


K.3.7 Link Channel States 


A iink channel is defined as the means of transmission for one direction. 


K.3.7.1 Active State 


A link channel is in an active condition when the link station is actively 
transmitting an LPDU. 


K.3.7.2 Idle State 


A link channel is defined to be in an idle condition when the link station fails to 
receive an LPDU for a system specified period of time. 


K.4 ELEMENTS OF PROCEDURE 


The elements of procedure are defined in terms of actions that occur on receipt of 
commands or responses or the occurrence of events, at ELLC link stations. 


The elements of procedure specified here contain a selection of commands and responses 
relevant to the ELLC link connection and system configuration described in "Scope and 
Field of Application” on page II-K-2. 


A procedure derived from these elements of procedure is described in "Description of 
the Procedure” on page II-K-13. Together "LPDU Formats and State Variables" on page 
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II-K-5 and "Elements of Procedure” form the general requirements for proper management 
of link connections between ELLC link stations in adjacent nodes. 


K.%4.1 LPDU Formats and State Variables 


The various LPDU formats and link station state variables used for ELLC are described 
under "Control € C ) Field Formats” and "Control Field Parameters." 


K.4.1.1 Control ( C ) Field Formats 

The C field contains a command or a response, and sequence numbers, where applicable. 
Three LPDU C-field formats as shown tn Figure K-3 are defined for use: 

e IPDUs - to perform sequenced information transfers; 


° SPDUs - to perform numbered supervisory functions; and 
® UPDUs - to perform unnumbered control functions. 


Second Octet First Octet 
Control field bits 8765432 1 8 7 6 5 4 3 2 1 
LNr | | 


Supervisory (SPDU) LNr P/F bx x x | x | 
Sr a OH KW 


LNs = transmitter send sequence number (bit 2 = low order bit). 
LNr = transmitter receive sequence number (bit 2 = low order bit). 
S = supervisory function bit. 
M = modifier function bit. 
P/F = poll (P) bit in command frames or final (F) bit in response 


frames (1 = Poll/Final). 


Figure K-3. LPDU: Control Field Formats 


Information_Protocol_ Data_Unit - IPDU: used to perform sequenced information 

transfers. Except as otherwise specified (i.e., LPDUR, LTEST, LXID) it is the only 

LPDU that may contain an information field. The functions of LNs, LNr and P/F are 
independent; i.e., each IPDU has an LNs, and an LNr which may or may not acknowledge 

ea IPDUS received by the ELLC link station transmitting the LNr, and a P/F 
it. 7 


Supervisory_Protocol Data_Unit - SPDU: used to perform link supervisory control 
functions such as acknowledging IPDUS, requesting retransmission of IPDUs, and 
requesting temporary suspension of IPDU transmission. 


Unnumbered_Protocol_ Data_Unit - UPDU: used to provide additional link control 
functions. This format contains no sequence numbers. 


K.4.1.2 Control Field Parameters 

Parameters associated with the control field formats include a modulus (m), LPDU 
variables and sequence numbers. 

Modulus - 'm': IPDUs are sequentially numbered and may have the value 'LNs=0' through 
"LNs=m minus onet (where 'm' is the modulus of the sequence numbers). 'm’ is equal to 
"128" and the sequence numbers cycle through the entire range '0' to '127", inclusive. 


State Variables and Sequence Numbers: 


1. Link Send State Variable ( LVs ) 
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LVs denotes the sequence number of the next in-sequence IPDU to be transferred 
across the link connection. LVs can take on the value '0' through 'm minus one’. 
The value of LVs is incremented by one with each successive IPDU transferred but 
at originating link stations cannot exceed LNr of the last received IPDU or SPDU 
by more than the maximum permissible number of outstanding IPDUs (Lk). The value 
of eet is defined in "Maximum Number of Outstanding IPDUs - ¢€ Lk )" on page 
II-K-23. 


2. Link Send Sequence Number (€ LNs ) 


Only IPDUs contain LNs, the send sequence number of transferred PDUs. Prior to 
transferring an in-~sequence IPDU, the value of LNs is set equal to the value of LVs 
at the originating link station. 


3. Link Receive State Variable ( LVr ) 


LVr denotes the sequence number of the next in-sequence IPDU to be received at 
destination link stations. LVr can take on the values "0° through 'm minus one’. 
The value of LVr 18 incremented by one upon receipt of each error free, 
Iin-sequence (with an LNs that is equal to the current value of LVr at the receiving 
link station) IPDU. 


4. Link Receive Sequence Number ( LNr ) 


All IPDUs and SPDUs contain LNr, the expected sequence number of the next received 

IPDU. Prior to transmitting an IPDU or SPDU, LNr is set equal to the current value 

of LVr at the originating link station. LNr indicates that the link station 

oo ee LNr has correctly received all IPDUs numbered up to and including 
rminus . 


K.4.1.3 Functions of the Poll/Final Bit 


The poll/final (P/F) bit serves a function in both command LPDUs and response LPDUs. 
In command LPDUs the 'P/F' bit is referred to as the Poll (P) bit. In response LPDUs 
it is referred to as the Final (CF) bit. | 


Procedures for use of the 'P/F’ bit are described in "Procedure for Use of the P/F Bit" 
on page II-K-14. 


K.4.2 Link Commands and Responses 


Command and response LPDUs transmitted and received by link stations in adjacent nodes 
are depicted in Figure K-4 and are described in "LLC_Information € LI ) Command" on 
page II-K-?7 through "LLC_Test ( LTEST ) Command and Response” on page II-K-10. 
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First Octet 


Ee Positions 


8765432 


5 43 


LNs 


= Ea 
| LREJ | | LREJS 


ere 


(CU) 
a ok 


| LSABME{ 
LDISC 


Disconnect 

Disconnected Mode 
Protocol Data Unit Reject 
Information 

Reject 

Receive Not Ready 

Receive Ready 


Unnumbered Acknowledgment 
Exchange Identification 
Test 


Set Asynchronous Balanced Mode — Extended 


Link stations transmit all Supervisory and Unnumbered command 


LPDUsS with 'P=l1"'. 


Figure K-4. LPDU: Commands and Responses 


K.4.2.1 LLC_Information ( LI } Command 


LI commands are used to transfer sequentially numbered PDUs that contain informati 
fields, across link connections between link stations in adjacent nodes. 


K.4.2.2 LLC_Receive_Ready ( LRR } Command and Response 


LRR command/response SPDUs are used by link stations to: 


1. indicate that they are prepared to receive IPDUs 


2. acknowledge previously received IPDUs numbered up to and including 'LNr minus 1". 


LRR command/response SPDUs may be used to clear busy conditions initiated by the prior 
transmission of LRNR command/response SPDUs. LRR command SPDUs with 'P=1' may be used 


by link stations to solicit the status of the communicating link station 


adjacent node. 
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K.4.2.3 LLC_Reject ( LREJ ) Command and Response 


LREJ command/response SPDUs are used by link stations to request retransmission of 
IPDUs starting with the IJPDU numbered LNr. IPDUs numbered ‘'LNr minus 1' and below are 
acknowledged. Additional IPDUs pending initial. transmission may be transmitted 
following the retransmitted IPDU(s). | 


Only one LREJ exception condition for a given direction of barernstion transfer may be 
established at any time. LREJ exception conditions are cleared (reset) upon receipt 
of an IPDU with an LNs equal to the LNr contained in the LREJ SPDU. 


K.4.2.4 LLC_Receive_Not_Ready ( LRNR ) Command and Response 


LRNR command/response SPDUsS are used by link stations to indicate busy conditions; 
1.@., temporary inability to accept additional IPDUs. IPDUS numbered up to and 
including 'LNr-1l' are acknowledged. IPDU LNr and subsequent IPDUsS reccived, if any, 
eee acknowledged; the acceptance status of these IPDUs is indicated in subsequent 
exchanges. 


Indication that a busy condition at a link station has cleared is communicated to the 
een ee station in the adjacent node by the transmission of an LUA, LRR, 
or BME. 


LRNR command SPDUs with the '"P=1" may be used by link stations to solicit the status of 
the communicating Link station in adjacent nodes. 


K.4.2.5 LLC_Set_Asynchroenous_Balanced_Mode_Extended (€ LSABME. ) Command 


LSABME commands are used to initialize/re-initialize both directions of transmission 
across the link connection between link stations in adjacent nodes. The DLC.X25.CM 
Initiates transmission of the LSABME command upon receipt of a "CONTACT_ALS” from 
SNA.PU. No information field is permitted with this command. Link stations in 
adjacent nodes confirm acceptance of LSABME commands by transferring an LUA response 
across the link connection at the earliest opportunity. Upon acceptance of an LSABME 
command, the communicating link station in the adjacent node sets both its send and 
receive state variables (LVs and LVr) equal to '0" and assumes the link asynchronous 
balanced mode - extended. When the LUA response is correctly received, the initiating 
link station also assumes the link asynchronous balanced mode - extended and sets its 
send and receive state variables (LVs and LVr) equal to '0". LSABME commands are 
always transferred with 'P=1"'. 


Previously transferred IPDUs that are unacknowledged when the LSABME command its 
initiated and executed remain unacknowledged (see "Waiting for Acknowledgment” under 
"Procedures for Information Transfer” on page II-K-16). Any transmit buffers that are 
unacknowledged or pending initial transmission are purged from the link station queue 
and returned to the upper level user function. 


K.4.2.6 LLC_Disconnect ( LDISC ) Command. 


LDISC commands are used by Link stations to terminate the operational mode previously 
set. LDISC informs the communicating link station in the adjacent node that the link 
station is temporarily suspending operation. 


No information field is permitted with LDISC commands. Prior to executing LDISC 
commands, receiving link stations confirm acceptance by transmitting an LUA response. 
Transmitting link stations enter the link disconnected phase upon receipt of the 
acknowledging LUA response. LDISC command LPDUs are always transmitted with "P=1'. 


Previously transmitted IPDUs that are unacknowledged when the LDISC command 15 


executed remain unacknowledged (see Waiting for Acknowledgment under "Procedures for 
Information Transfer" on page JI-K-16). 
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K.4.2.7 LLC_Unnumbered_Acknowledgment ( LUA ) Response 


LUA responses are used by originating link stations to acknowledge receipt and 
indicate acceptance of LSABME and LDISC commands. Receiving link stations transfer an 
LUA response before executing the received UPDU command. The LUA response is 
transferred with "F=1" when 'P=1'" in the received UPDU command. No information field 
1s permitted with LUA responses. 


K.4.2.8 LLCO_Disconnected_Mode ( LDM ) Response 


LDM responses are used to report a status where the originating link station is 
logically disconnected, and is in the LLC disconnected phase. The LDM response may be 
sent in response to a received LSABME command, to inform the adjacent node link 
station that the originating link station is still in the LLC disconnected phase and 
cannot execute the LSABME command. No information field is permitted with the LDM 
response. 


Link stations in the link disconnected phase monitor received commands and: 


1. react to LSABME and LDISC commands as described in "Link Disconnected Phase" on 
page IJI-K-15; and, 


2. transfer an LDM response with 'F=1' to any other UPDU command received with "P=1'. 


K.4.2.9 LLC_Protocol_ Data_Unit_Reject ( LPDUR ) Response 


LPDUR responses are used by link stations to report error conditions that are not 
recoverable by retransmission of the identical LPDU to the adjacent link station} 
1.@., one of the following conditions, resulting from the otherwise error free receipt 
of an LPDU with: 

1. a LPDU command or response that is invalid or not implemented; 

2. an information field that exceeds the maximum permissible length; 

3. an invalid LNr; or, 


4. an information field which is not permitted or an SPDU or UPDU of incorrect 
length. | 


An invalid LNr is one that points to an IPDU that has been previously transmitted and 
acknowledged or to an IPDU that has not been transmitted and is not the next sequential 
IPDU pending transmission. 


An information field which immediately follows the control field, and consists of 5 
octets, 1s returned with the LPDUR response. This format is shown in Figure K-5. 
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Rejected LPDU 
Control Field 


- Rejected LPDU control field is the control field of the received LPDU that 
caused the PDU reject condition. | | 

- LVs is the current value of LVs at the link station reporting the rejec- 
tion condition (bit 23 = low order bit). 

- LVr is the current value of LVr at the link station reporting the rejec~ 
tion condition (bit 31 = low order bit). 

- 'W=1" indicates that the control field received and returned in bits 1 
through 16 was considered invalid or not implemented. 

- "X=1' indicates that the control tield received and returned in bits l 
through 16 was considered invalid because the LPDU contained an informa- 
tion field which is not permitted or is an SPDU or UPDU with incorrect 
length. ‘'W=1' is required in conjunction with this bit. 

- "Y=1' indicates that the information field received exceeded the maximum 

. established capacity of the link station reporting the condition. 

- 'Z=1' indicates that the control field received and returned in bits 1 
through 16 contained an invalid LNr. 

- C/R - Bit 32 is set to: 

"lL" if the rejected LPDU was a response; or, 
‘O' if the rejected LPDU was a command. 


Figure K-5. LPDUR: Information Field Format 


K.4.2.10 LLC_Exchange_Identification (€ LXID ) Command and Response 


LXID commands are used by ELLC link stations to initiate exchanges of identification 
information with link stations at the adjacent SNA nodes. 


K.4.2.11 LLC_Test ( LTEST ) Command and Response 


LTEST commands are used by ELLC link stations to initiate tests of link connections 
and solicit an LTEST response from ELLC link stations in adjacent nodes. 


K.4.3 Exception Condition Reporting and Recovery 


Procedures to effect recovery following the detection/occurrence of exception 
conditions on the connection between Link stations in adjacent SNA nodes are described 
in "Busy Condition” through "LPDU Rejection Condition” on page II-K-12. Exception 
conditions described include situations that may occur as the result of underlying 
network malfunctions or abnormal operational situations. 


K.4.3.1 Busy Condition 


A busy condition results when an ELLC link station is temporarily unable to continue 
receiving IPDUs due to internal constraints (e.9g., receive buffering limitations). 
Notification of the busy condition is conveyed to the link station in the adjacent 
node by transferring an LRNR across the link connection. IPDUS pending transmission 
may be transmitted by link stations experiencing a busy condition, either prior to, or 
following, transmission of the LRNR. Recovery from a link station busy condition is 
indicated to link stations in adjacent nodes as described in "LLC_Receive_Not_Ready ( 
LRNR }) Command and Response" on page II-K-8. 
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K.4.3.2 LNs Sequence Error 


A sequence exception condition results when an error-free (no PDUCS error) IPDU with 
an LNs that is not equal to the current value of LVr at the receiving link station is 
received. Receiving link stations do not acknowledge Cincrement their LVr) IPDUs that 
result in sequence exception conditions. 


The information field of all IPDUS received with an LNs that is not equal to the 
current value of LVr at the receiving link station is discarded. 


ELLC link stations that receive one or more IPDUS having sequence errors but otherwise 
error-free accept the control information contained in the LNr field and the 'P* bit 
to perform link control functions (e.g., to receive acknowledgment of previously 
transmitted IPDUs and to cause the link station to respond ('P=1")). Therefore, 
retransmitted IPDUs may contain an LNr field and '‘'P" bit that are updated, and 
therefore different from, those contained in the IPDUCs) originally transmitted. 


K.4.3.3 LLC REJECT Recovery 


LREJ commands and responses are transferred by link stations to initiate exception 
recovery Cretransmission) following detection of sequence errors. 


Only one "sent LREJ"™ exception condition for a link station is established at a time. 
A “sent LREJ" exception condition is cleared when the requested IPDU is received; or, 
when a link set-up or disconnection procedure as described in “Link Resetting 
Procedures" under "Procedures for Information Transfer™ on page II-K-16 is performed. 


Link stations receiving LREJ initiate sequential Cre-)Jtransmission of IPDUs starting 
— the one indicated by the LNr contained in the received LREJ SPDU,-if possible (see 
~-K.6.5.4). 


K.4.3.4 Time-out Recovery 


If, due to a transmission error, a link station does not receive (or receives and 
discards) a single IPDU or the last IPDU in a sequence of IPDUs, it cannot detect an 
out-of-sequence exception condition and will, therefore, fail to transmit an LREJ. 
Link stations shall, following completion of a system specified time-out period (see 
"List of LLC Parameters" on page JI-K-20) take appropriate recovery action to 
determine at which IPDU retransmission must begin. 


Link stations use the lost reply protection mechanism, described in "Lost Reply 
Protection” on page II-K-14, after a system specified time-out period (see "List of 


LLC Parameters" on page JI-K-20) to determine at which IPDU to begin retransmission. 


K.4.3.5 Protocol Data_Unit_Checking_Sequence ( PpucS ) 
The purpose of the PDUCS is to detect LPDUs that have been corrupted by the underlying. 
network service. 


When an LPDU is to be transmitted the sending link station must generate a PDUCS for 
the LPDU and store it in the PDUCS parameter in the LPDU header. 


1. PDUCS € Checksum ) Generation Procedure 
a. Set up the complete LPDU, including the header and user data (if any). The 
header must include the PDUCS parameter. The value field of the PDUCS 
parameter must be set to zero at this point. 
b. Initialize two variables (called C® and C!) to zero. 
c. For each octet of the LPDU, including the header and the user data Cif any), 
add the octet value to CC®, and then add the value of CC® to C!. Octets are 


processed sequentially, starting with the first octet and proceeding through 
the LPDU. Addition 1s performed modulo 256. . : 
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d. Calculate the value field of the PDUCS parameter as follows: 


e Let the length of vile LPDU, i1.e., the number of times the above operation 
was repeated be ' | 3 ie 


e Let the first octet of the PDUCS value, i.e., the one at offset "i' ( where 
: "7=5"' 0, be called 'X'; , 


° Let the second octet, at offset 'j" ( where 'j=4" ), be called "YY". (Where 
the first byte of the LPDU is considered to be at offset '1'). 


Then: 


CCCL - 1) * C9) ~- CC!) modulo 256; and, 
CCCL - 5d * C- C°)) + Ct) modulo 256 


e. ie the computed values of 'X' and 'Y* in the appropriate octets of the 
LPDU. 


Notes An implementation may use one's complement arithmetic as an 
alternative to modulo 256 arithmetic. However, if either of the PDUCS octets 
*X' and 'Y' has the value minus zero (i.e., x'FF') then it must be converted to 
Plus zero (it.e., x'00') before being stored. 


2. PbDUCS ( Checksum ) Validation Procedure 


When an LPDU is received it is verified to ensure that it has been received 
correctly. This is done by computing the PDUCS, using the same algorithm by which 
it was generated. The nature of the PDUCS algorithm is such that it is not 
necessary to compare explicitly the stored PDUCS octets. The procedure described 
below may be used to verify that an LPDU has been correctly received. 


Initialize two variables (called C® and C!) to zero. 


b. For each octet in the received LPDU, add the value of the octet to C® and then 
add the value of C® to C?, starting with the first octet and proceeding 
sequentially through the LPDU. All addition is performed modulo 256. 


c. When all octets have been sequentially processed, the values of C® and C?! 
should be zero. If either or both of them jis non-zero, the LPDU has been 
received incorrectly and the verification has failed. Otherwise, the LPDU has 
been received correctly and the LPDU is processed normally. 


Note: An implementation may use one's complement arithmetic as an 
alternative to modulo oe arithmetic. In this case, if either C® or C? has the 
value minus zero Ci. x'FF') it is regarded as though it was plus zero 
Ci.e., x'00'). 


If a PDUCS verification failure occurs, the received LPDU is discarded and no 
actions is taken by any link station at the receiving DTE as a result of that LPDU. 


K.4.3.6 LPDU Rejection Condition 


An LPDU rejection condition may be established upon receipt of an error-free LPDU that 
contains an invalid command/response in the C field, an invalid LPDU formats an 
invalid tNr or an information field that exceeds the maximum information field length 
that can be accommodated. 


Receiving ELLC link stations report LPDU rejection conditions to the communicating 
link station in the adjacent node by transferring an LPDUR response across the link 
connection. ELLC link stations that receive an LPDUR response are responsible for 
resolving the rejection condition by initiating either a link resetting or link 
disconnection procedure; or, by causing a clearing or resetting of the underlying 
virtual circuit. After transmitting an LPDUR response, ELLC link stations maintain 
the LPDU rejection condition until the link is reset by the communicating link station 
in the adjacent node. IPDUs received by ELLC link stations in the LPDU rejection 
condition are discarded, except for the 'P' bit indication (LNr is ignored). The 
LPDUR response may be repeated at each opportunity until recovery is effected by the 
communicating link station in the adjacent node, or until internal recovery is 
initiated locally. 
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K.4.3.7 Recoverable Packet Level Error Conditions 


Network initiated virtual circuit terminations (clears) and re-synchronizations 
(resets), as well as interface re-initializations (restarts) considered to be 
potentially recoverable at the logical link control level include those resulting from 
the receipt of indication packets with the Cause Codes shown in Figure K-6, Figure K-7 
and Figure K-8. 
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Number busy 
Out of order 
Access Barred 


Remote Procedure Error 
Local procedure error 


Network congestion 
Not obtainable 
RPOA out of order 
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Figure K-6: Recoverable CLEARING Cause Codes 


RESETTING CAUSE 


Out of order 

Remote procedure error 
Local procedure error 
Network congestion 
Remote DTE operational 
Network operational 
Incompatible destination 


Figure K-7. Recoverable RESETTING Cause Codes 


Local procedure error 
Network congestion 
Network operational 


Figure K-8. Recoverable RESTARTING Cause Codes 


K.5 DESCRIPTION OF THE PROCEDURE 


The charts in "LINK STATION STATES AND ACTIONS” on page II-K-25 detail the actions 
taken, LPDUs transferred and state transitions made by ELLC link stations as a result 
of stimuli that can occur in various states of the link connection. 


K.5.1 Procedure for Addressing 


LPDUs are transferred with the address field set to indicate their command/response 
content. 


APPENDIX K: Enhanced Logical Link Control -— ELLC II-K-13 


SNA/X.25 DTE/DCE Interface 
K.5.2 Procedure for Use of the P/F Bit 


Upon receipt of any command LPDU with ‘'‘'P=1", ELLC link stations transfer an 
appropriate response LPDU with 'F=1' across the link connection at the first respond 
opportunity (Ce.g., immediately following the LPDU currently being transmitted, if 
any). Appropriate responses include: 


1. an LUA or LDM response to received LSABME and LDISC commands; 

2. an LPDUR, LREJ, LRNR or LRR response to received IPDU commands; and, 

3. an LXID or LTEST response to received LXID or LTEST commands, respectively; 
4. an LPDUR, LRNR or LRR response to received SPDU commands. 


The 'P* bit is also used in conjunction with timer recovery conditions as described in 
"Waiting for Acknowledgement" on page II-K-18 and may be used as a request for 
acknowledgment on IPDUS and invitation to transmit, by the upper level user(s), in 
application environments that exhibit half-duplex characteristics. | 


K.6 LOST REFLY PROTECTION 


ELLC link stations provide a time-out function to protect against dead-lock conditions 
caused by loss of responses from communicating link stations in the adjacent node due 
to transmission errors. An LLC Reply Timer, LT1, may be started upon transmission of 
IPDUs or SPDU commands, or both, during the information transfer phase. Link Reply 
Timer, LT1, is also used as described in "Link Set-up” and "Link Disconnection” on 
page I[I-K-15. : 


If Link Reply Timer, LT1, expires prior to receipt of an appropriate response from the 
communicating link station in the adjacent node, ELLC link stations initiate action to 
recover the link connection. ELLC link stations transfer an appropriate command SPDU 
and restart Link Reply Timer, LT1. If Link Reply Timer, LT1l, expires prior to receipt 
of = appropriate response with '‘'F=1' LN2 times, appropriate recovery action 1s 
initiated. 


K.6.1 Procedures for Link Set-Up and Disconnection 
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K.6.1.1 Link Set-up 


ELLC link stations wishing to set-up the link connection transfer an LSABME command 
with "P=1" and start Link Reply Timer, LT1 (see "LLC_Time-Out_Function - (€ LFt 0" on 
page II-K-20. Upon receipt of an LUA response with 'F=1' from the link station in the 
adjacent node, the initiating ELLC link station sets both LVs and LVr equal to '0' and 
stops link Reply Timer, LTl. 


Upon receipt of an LSABME command, receiving ELLC link stations prepared to receive 
IPDUs return an LUA response and set both LVs and LVr equal to "0". ELLC link stations 
that, for some reason; are unable or do not desire to enter the information transfer 
phase, return an LDM response to received LSABME commands. 


Upon receipt of an LDM response with 'F=1'" indicating that the adjacent link station 
cannot accept activation of the link connection, the condition is reported to the 
upper level user and no further action is taken by logical link control. 


Upon expiration of Link Reply Timer, LT1, prior to receipt of an appropriate response | 
with 'F=1', ELLC link stations perform the retransmission procedure described in 
"LLC_Time-Out_Function - ( LFt )" on page II-K-20 before declaring the link connection 
to be inoperative and reporting the condition to a higher level of SNA. 
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K.6.1.2 Information Transfer Phase 


FELLC link stations, having transferred an LUA response to a received LSABME command or 
having received an LUA response to a transmitted LSABME command, accept and transmit 
IPDUS and SPDUS in accordance with the procedures described in "Procedures for 
Information Transfer” on page II-K-16. 


Upon receipt of an LSABME command, an LUA response or an LDM response with 'F=0', while 
in the information transfer phase, ELLC link stations conform to the resetting 
procedure described in "Link Resetting Procedures" on page II-K-18. 


K.6.2 Link Disconnection 


During the information transfer phase ELLC link stations, wishing to terminate the 
link connection, transfer an LDISC command with 'P=1' across the link connection and 
start Link Reply Timer, LT1, (see "LLC_Time-Out_Function - € LFt )" on page II-K-20). 


Upon receipt of a LDISC command, receiving ELLC link stations return an LUA or LDM 
response and enter the link disconnected phase. 


Upon receipt of an LUA or LDM response with 'F=1' from the communicating link station 
in the adjacent node, initiating ELLC link stations stop Link Reply Timer, LT1. 


Upon expiration of Link Reply Timer, LT1l1, prior to receipt of an appropriate response 
with ‘"F=1"', ELLC link stations perform the retransmission procedure described in 
PLLC Time-Out_Function - (€ LFt J" on page II-K-20 before declaring the link connection 
to be inoperative and reporting a failure to the higher levels of SNA. 


K.6.2.1 Link Disconnected Phase 


ELLC link stations, having received an LDISC command and returned an LUA response, or 
having received an LUA response to a transmitted LDISC command, enter the link 
disconnected phase. 


ELLC link stations, in the link disconnected phase, may initiate link set-up. While 
in the link disconnected phase, ELLC link stations react to the receipt of LSABME 
commands as described in "Link Set-up”™ on page IJI-K-14 and transfer an LDM response to 
received LDISC commands. 


Upon receipt of any command (other than LSABME) with '"P=1', receiving ELLC link 
stations transfer an LDM response with 'F=1'. 


Other LPDUs are ignored by receiving ELLC link stations while in the link disconnected 
phase. 


K.6.2.2 Collision of UPDU Commands 


UPDU command collision situations are resolved in the following manner. 


Like Commands: When the sent and received UPDU commands are the same, both ELLC link 
stations transfer.an appropriate UPDU response at the earliest possible opportunity. 
ELLC link stations place the associated link connection in the indicated state upon 
receipt of the appropriate UPDU response. 


Unlike Commands: When the sent and received UPDU commands, other than LXID and LTEST, 
are different ELLC link stations place the associated link connection in the 
LINK_CLOSED state and transfer an LDM response at the earliest possible opportunity. 
When the sent and received UPDU commands are LXID or LTEST, ELLC link stations 
transfer the appropriate LTEST and LXID response, respectively, when available. 
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K.6.3 Procedures for Information Transfer 


These procedures apply to the transmission of IPDUs in each direction of transmission 
during the link information transfer phase. 


In the following text, "number one higher™ is in reference to a continuously repeated 
sequence series, i.e., "127" is one higher than '126' and '0' is one higher than '127' 
for modulo one hundred twenty eight series. 


K.6.3.1 Sending IPDUs 


ELLC link stations having IPDUs to transfer Ci.e., IPDUS not already transferred, or 
having to be retransmitted as described in "Receiving Reject” on page IJI-K-17 or 
"Waiting for Acknowledgement” on page II-K-18, transfer them with an LNs equal to the 
current value of that link stations LVs, and an LNr equal to the current value of the 
link stations LVr. Upon completion of transmission of each successive IPDU, ELLC link 
stations increment their LVs by one (1) and start Link Reply Timer, LT1l, if it is not 
already running. 


When the value of LVs, at an ELLC link station, is equal to the last value of LNr 
received from the communicating link station in the adjacent node plus 'Lk’' (where 
"Lk' 3s the maximum permissible number of outstanding IPDUS allowed (see "Maximum 
Number of Qutstanding IPDUs - (€( Lk )" on page II-K-23), that ELLC link stations does 
not transfer any new IPDUs, but may retransmit IPDUs as described in "Receiving 
Reject” on page II-K-17 or "Waiting for Acknowledgement" on page II-K-18. 


Note: To ensure the integrity of information transfer, ELLC link stations do not 
transfer any IPDUs when the link stations LVs is equal to the last value of LNr 
received from the link station in the adjacent node plus '127'. 


ELLC link stations in the busy condition may continue to transfer IPDUs, provided the 
communicating link station in the adjacent node is not also ina busy condition. ELLC 
link stations in the link rejection condition, do not transfer IPDUs. 


K.6.3.2 Receiving IPDUs 


ELLC link stations not in the busy condition accept the I-field of in sequence IPDUs 
CIPDUs with an LNs equal to the current value of the link stations LVr) received with 
the correct PDUCS, increment the value of the link stations LVr by one and acknowledge 
receipt of the IPDUCs) by transferring: 


e the next sequential IPDU to be transferred, if it is available, or an LRR response 
SPDU with LNr equal to the current value of tts LVr; or, 


e an LRR response SPDU response with LNr equal to the current value of its LVr, if no 
IPDU is available to transfer. 


ELLC link stations may ignore the information field contained in IPDUsS receive while 
they are in a. busy condition. 


Notes ELLC link stations treat IPDUs with zero length information fields the same as 
any other IPDU at the link station. 


K.6.3.3 Receipt of Incorrect LPDUS 


ELLC link stations ignore LPDUs received with an incorrect PDUCS and cause a clearing 
or resetting of the underlying virtual call or permanent virtual circutt, 
respectively, upon receipt of LPDUs with invalid formats (see "Invalid LPDUs™ on page 
TI-K-4). 


ELLC link stations receiving IPDUS with the correct PDUCS, but with an incorrect LNs 
Ci.e., one that is not equal to the current value of LVr at the receiving link station) 
discard the I-field and transfer an LREJ response with an LNr one higher than the LNs 
contained in the last correctly received IPDU. Then they discard the I-field, but use 
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the LNr and 'P* bit indications of all IPDUs received with an LNs that is not equal to 
the current value of LVr at the receiving ELLC link station. Upon receipt of the 
expected IPDU Ci.e., one with an LNs equal to the current value of LVr), receiving 
ee Ae stations acknowledge the IPDU as described in "Receiving IPDUs" on page 
TI-K-16. 


K.6.3.4% Receiving AcknoNledgement 


ELLC link stations, even in a busy condition, consider the LNr contained in correctly 
received IPDUs or SPDUs (C(LRR, LRNR and LREJ) as acknowledgment for all IPDUs 
transferred with an LNs up to and including '"LNr minus 1". ELLC link stations reset 
Link Reply Timer, LT1, upon correct receipt of an IPDU or SPDU that actually 
acknowledges some previously transferred IPDUCsS) Ci.e., an LPDU with an LNr higher 
than the value of the last LNr received); or, upon receipt of an SPDU with. 'F=1"'. 


If Link Reply Timer, LT1, has been reset with IPDUCsS) still unacknowledged, ELLC link 
stations restart Link Reply Timer, LT1. If Link Reply Timer, LT1, expires prior to 
receipt of an acknowledgment, ELLC link stations follow the retransmission procedure 
described in "Receiving Reject" and "Waiting for Acknowledgement" on page II-K-18 with 
respect to the unacknowledged IPDU(s). 


K.6.3.5 Receiving Reject 


Upon receipt of an LREJ SPDU, receiving ELLC link stations, supporting LPDU 
retransmission recovery (see §-K.6.5.4), set LVs equal to the LNr contained in the 
received LREJ, then transfer the corresponding IPDU when it is available or retransmit 
it; otherwise, they cause a clearing or resetting the the virtual circuit. 


Sane link stations conform to the following with respect to the re-transmission of 
IPDUs: 


1. An ELLC link station that is transmitting a SPDU or an UPDU when it receives a 
LREJ, will complete the transmission in progress before commencing transmission of 
the requested IPDU. 


2. An ELLC link station that is transmitting an IPDU when an LREJ is received, may 
abort transmission of the IPDU and commence transmission of the requested IPDU 
immediately after abortion. 


3. An ELLC link station that is not transmitting any LPDU when an LREJ is received, 
will commence transmission of the requested IPDU immediately. 


Other unacknowledged IPDUs already transferred, following the one indicated in the 
LREJ, are retransmitted following retransmission of the requested IPDU. 


If the LREJ was received as a& command with 'P=1"', receiving ELLC link stations 
transfer an LRR or LRNR response with 'F=1' prior to transmitting or retransmitting 
the corresponding IPDU. 


K.6.3.6 Receiving LRNR 


Upon receipt of an LRNR command or response SPDU, ELLC link stations may start timer 
LIin if it is not running. If timer LTn then expires prior to the receipt of a LUA, 
LRR, LREJ or LSABME from the communicating link station in the adjacent node, ELLC 
link stations transmit an appropriate SPDU command with P=1 and may perform the 
retransmission procedure described under "LLC_Time-Out_Function - € LFt 2” on page 
II-K-20 before declaring the link connection to be inoperative and reporting the 
condition to upper level user(s). 
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K.6.3.7 Link Station Busy Condition 


ELLC link stations experiercing a busy condition transfer an LRNR command or response 
at the earliest opportunity. While in the busy condition, ELLC link stations accept 
and process SPDUs and respond LRNR with "F=1' to IPDUsS and SPDU commands received with 
"P=1'. To clear a busy condition, ELLC link stations transfer either LREJ commands or 
responses or LRR commands or responses with LNr set to the current value of LVr, 
habe on whether or not information fields of correctly received IPDUs were 
discarded. 7 


K.6.3.8 Waiting for Acknowledgement 


Originating ELLC link stations maintain an internal retransmission count CY) which is 
set equal to ‘0’ upon receipt of an LUA or LRNR, or upon correct receipt of an IPDU or 
an SPDU with an LNr higher than the last LNr received from the communicating link 
station tin the adjacent node Cactually acknowledging some IPDU(s)). 


If Link Reply Timer, LT1, expires, ELLC link stations enter or Cre-)Jenter the timer 


recovery condition, increment 'Y* by one (1) and set an internal variable (X) to the 
current value of LVs. 


ELLC link stations restart Link Reply Timer, LT1, set LVs equal to the value of the 
last UNr received from the communicating link station in the adjacent node and 
transfer an appropriate SPDU command with '"P=1'. 


Timer recovery conditions are cleared upon receipt of a valid SPDU response with 
'F=17 


Upon correct receipt of a SPDU response with 'F=1" and an LNr within the range from the 
current value of LVs to 'X' included, ELLC link stations reset the timer recovery 
condition and set LVs equal to the value of LNr in the received SPDU. 


Upon correct receipt of an SPDU with 'F=0" and with an LtNr within the range from the 
current value of LVs to 'X* included, ELLC link stations do not reset the timer 
recovery condition. The received LNr may be used to update LVs. 


When "*Y*® is equal to LN2, ELLC link stations initiate a resetting procedure as 
described in "LLC Rejection Conditions" on page IJI-K-19 The value of LN2 is a system 
parameter (see "Maximum Number of LPDU Transmissions —- (€( LN2 )" on page II-K-22). 


K.6.3.9 Link Resetting Procedures 


The resetting procedures described here are used, only on link connections perceived 
by the ELLC link station to be in the information transfer phase, to (re)-initialize 
both directions of information transfer. 


1. Local Reset 


ELLC link stations indicate a resetting of the link by transferring an LSABME 
command LPDU across the link connection. Upon receipt of an LSABME command, ELLC 
link stations prepared to resume normal operation of the link, return an LUA 
response at the earliest opportunity, and set LVs and LVr equal to '0". This also 
clears link station busy conditions, if present. Prior to initiating this link 
resetting procedure, ELLC link stations may initiate a link disconnection 
procedure as described in “Remote Reset” below. 


2. Remote Reset 


Under certain rejection conditions listed in "LLC Rejection Conditions” on page 
TI-K-19, ELLC link stations may request the adjacent link station to reset the 
link by transferring an LPDUR response. : 


After transmitting an LPDUR response, originating ELLC link stations enter the 
link rejection condition. The link rejection condition is cleared when the ELLC 
link station receives an LSABME or an LDISC command or an LDM response from the 
communicating link station in the adjacent node. Other LPDU commands received 
while in the link rejection condition cause receiving ELLC link stations to 
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retransmit the LPDUR response with the same information field originally 
transferred. 


Upon receipt of an LPDUR response, ELLC link stations prepared to resume normal 
operation of the link transfer an LSABME command LPDU with ‘'P=1' across the link 
connection and start Link Reply Timer, LT1. Otherwise, ELLC link stations 
initiate the link disconnection procedure described in "Link Disconnection" on 
page II-K-15; or, cause a clearing or resetting of the underlying virtual circuit. 


ELLC link stations may start Link Reply Timer, LT1l, on transferring the LPDUR 
response. If Link Reply Timer, LT1, then expires prior to the receipt of an LSABME 
or a LDISC command from the communicating Link station in the adjacent node, ELLC 
link stations may retransmit the LPDUR response and restart Link Reply Timer, LTl. 
Following transmission of the LPDUR response LN2 times ELLC link stations may 
reset the link as described in "Link Resetting Procedures" on page II-K-18. The 
value of LN2 is defined in “Maximum Number of LPDU Transmissions - (€ LN2 3" on page 
LI-K-22. 


K.6.3.10 LLCO Rejection Conditions 


ELLC link stations may initiate a resetting procedure as described in "Link Resetting 
Procedures" on page II-K-18 upon receipt, during the information transfer phase, of an 
LPDU with the correct PDUCS, and with one of the following conditions: 

1. the LPDU is unknown as a command or as a response; 

2. the LPDU does not conform to one of the valid formats; 

3. the LPDU information field is invalid; or, 


4. the LPDU contains an invalid LNr as defined in "LLC_Protocol Data_Unit_Reject ( 
LPDUR ) Response" on page II-K-3. 


Coding of the information field of LPDUR responses transferred is given in 
"LLC_Protocol_Data_Unit_Reject € LPDUR ) Response” on page II-K-9. 


Unsolicited LDM - ELLC link stations initiate a resetting procedure as described in 
"Link Resetting Procedures” on page II-K-18 upon receipt, during the information 
transfer phase, of an LDM response or an LPDUR response. 


Unsolicited Response - ELLC link stations may initiate a resetting procedure as 


described in “Link Resetting Procedures" on page II-K-18 upon receipt, during the 
information transfer. phase an LUA response or an unsolicited LPDU response with 'F=1". 


K.6.6 Link Connection Procedures 


K.6.4.1 Initial Connection Establishment 


The ELLC protocols employ the X.25 call set-up procedures described in -- Heading id 
"ch8! unknown ~-- for initial establishment of link connections. 


K.6.4.2 Connection Recovery 


Procedures are described to allow recovery from certain link connection failures, 
indicated by PSDNs, to be attempted at the LLC level when ELLC has been selected. Link 
failures reported by PSDNS in CLEAR_INDICATION, RESET_INDICATION and 
RESTART_INDICATION packets with the network generated Cause Codes listed in Figure 
K-6, Figure K-7 and Figure K-8 are assumed to be temporary in nature and, therefore, 
potentially recoverable. 


1. Clears 
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ELLC link stations attempt to re-establish virtual calls (switched virtual 
circuits) cleared by PSDNs via CLEAR_INDICATION packets that carry recoverable 
Cause Codes, as defined in Figure K-6, up to LN2 times before indicating 
link/station INOP to the higher layers of SNA. Connection recovery is initiated 
by transferring a CALL_REQUEST packet across the access channel, as depicted in 
Figure K-10. (5), indicating: 


LLC recovery mode; 
® connection recovery request; and, 
® connection identification information, if required. 


Upon receipt of an INCOMING CALL packet on a logical channel associated with a 
link connection perceived to have a connection recovery pending, ELLC link 
stations cause a clearing of the incoming call by transferring a CLEAR REQUEST 
packet with the Cause Code x'00", "DTE Generated’, and the diagnostic code x'5C', 
"Logical Channel Reserved". 


Resets 


ELLC link stations only need to log network initiated resets, of switched or 
permanent virtual circuits indicated by PSDNs via RESET_INDICATION packets that 
carry recoverable Cause Codes as defined in Figure K-7, for future problem 
determination purposes. Specific recovery action is not required in such 
instances since ELLC LPDU sequence numbering, acknowledgment and re-transmission 
procedures provide adequate data integrity mechanisms to cope with temporary 
failures in this category. 


Restarts 


ELLC iink stations treat network initiated restarts, of the X.25 DTE/DCE interface 
indicated by PSDNs via RESTART_INDICATION packets that carry potentially 
recoverable Cause Codes as defined in Figure K-8, as a clearing of all virtual 
sae and a resetting of all permanent virtual circuits at the X.25 DTE/DCE 
interface. 


K.6.5 List of LLC Parameters 


The LLC parameters are as follows: 


K.6.5.1 LLCO_Time-Out_Function - ( LFt ) 


Tha duration of the LLC time-out function CLFt) is: 


LFt = CLTLeLN2+LTd)eLNd 


where: 


LT1 1s a function of the time allowed by link stations between the 
transmission of commands and receipt of the corresponding 
acknowledgment. 


Upon expiration of timer-LT1, Link stations retransmit the 
unacknowledged command with "P=1' and restart timer LTl. 


LN2 2°1° is the maximum number of transmissions and retransmissions 
of a LPDU following the expiration of time LTl. 


LTd is typically many time greater than time LT1 and is the time to 
be delayed between consecutive repetitions of LTlLeLN2. 


LNd 2'1' is the maximum number of repetitions of LTLeLN2+LTd to be 
performed before declaring the logical link connection to 
be inoperative. 


Although LTd may be defined as zero, experience suggests that when LTd='"0!' and LNd="1" 
are used, link connections may often be declared inoperative prematurely, resulting in 
unnecessary session outages due to momentary network service disruptions. 
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It is, therefore, essential that LT1, LN2, LTd and LNd have default values that can be 
overridden by customers as experience indicates. 


ELLC link stat 


ions start Link Reply Timer, LT1, upon completion of transmission IPDUs 
or SPDU and UPDU commands with 'P=1'. 


The component parts of Times LT1 and LTn for link stations are illustrated in Figure 
K-9 to assist in the succeeding description of Time-limit LT2. 


LT1 | LTn 
E A T E R 
0 R A 0 A 
R Q K A K 
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A 
K 
D 


Propagation 
time 


Where: 
EOT - 


EOR - 


ARQ - 


T4 - 
LT1 & LTn 


Figure K-9. 


Process Maximum time Transmission Propagation Process 
time to seize line |time time time 


represents the end of transmission of the last bit of the LPDU 
requtring acknowledgment by the link station; 

represents receipt of the last bit of the LPDU requiring 
acknowledgment by the communicating link station in the 
adjacent node; 


represents recognition of the LPDU requiring acknowledgment by 
the. communicating link station in the adjacent node; 


represents transmission of the first bit of the acknowledging 
LPDU by the communicating link station in the adjacent node; 


represents transmission of the last bit of the acknowledging 
LPDU by the communicating link station in the adizacent node; 


represents receipt of the last bit of the acknowledging LPDU by 
the link station; 


represents recognition of the acknowledgment for the cutstanding 
LPDU at the link station; and, 


are the propagation times to and from the link station in the 
aaqjacent node station, respectively. 


are the stated processing times for the link station in the 
adjacent node and this link station, respectively. 


time to complete transmission of those LPDUsS in the acknowledging 
link station's "transmit queue" that are neither displaceable 

nor modifiable in an orderly manner. 

time to transmit the acknowledging LPDU. 


T2 + T2 + T3 + T% + T5 + T& Cminimum value). 


LINK REPLY TIMER - LT1: Components 


K.6.5.2 LRNR Time-out - ( LTn ) 
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K.6.5.3 LLCO Time-Limit - (€( LT2 ) 


Time~limit LT2 is the maximum time allowed between receipt of a command LPDU from the 
link station in the adjacent node and transmission of an appropriate response LPDU. 
This value 1s product and configuration specific. LT2 must never exceed the time 
needed to transmit one maximum length frame plus fifty (50) milliseconds. 


The duration of Time-limit LT2 is an LLC parameter that is determined by bilateral 
agreement between communicating link stations. The period of Timer-limits LT2' and 
LT2" for a link station and its counterpart in the adjacent node, respectively, take 
into account: 


1. the transmission time of the acknowledging LPDU; 
2. the propagation time across the link connection; 


3. the processing times for the link station and its counterpart in the adjacent 
node; and, | 


4. the time required to complete transmission of the LPDUs in the transmit queues, at 
both the link station and its counterpart in the adjacent node, that are neither 
displaceable nor modifiable in an orderly manner. 


For example, to insure receipt of an acknowledging LPDU before a link stations 
Link Reply Timer, LT1, expires, the communicating link station in the adjacent 
node must begin transmission of the acknowledging LPDU early enough to take the 
values of T*, T5 and T°, indicated above, into account. That is to say, the link 
station in the adjacent node must initiate transmission of the acknowledgment 
within at least time T* after ascertaining that an acknowledgment is required. 


For the direction of data transmission from a link station to its counterpart in the 
adjacent node, LT2' indicates the maximum amount of time allowed between receipt, at 
the link station in the adjacent node, of an LPDU requiring an acknowledgment and 
initiation of transmission, by the link station in the adjacent node, of the 
acknowledging LPDU to insure its receipt prior to the expiration of the link stations 
Link Reply Timer, LT1. The value of LT2' must be less than the value of LTl. 


For the direction of data transmission from a link station to its counterpart in the 
adjacent node, LT2' indicates the maximum amount of time allowed between receipt, at 
the link station in the adjacent node, of an LPDU requiring an acknowledgment and 
initiation of transmission, by the link station in the adjacent node, of the 
acknowledging LPDU to insure its receipt prior to the expiration of the link stations 
Link Reply Timer, LT1. The value of LT2" must be less than the value of LTl. 


goa a value for Link Reply Timer LT1, the value of Timer LT2' must be no greater than 
L less: 


- the propagation time across the link connection from the link station 
to its counterpart in the adjacent node; 

- the LPDU processing time at the link station in the adjacent node; 

~- the time required to transmit the acknowledgment from the link 
station in the adjacent node; 

- the propagation time across the link connection from the link station 
in the adjacent node; and, 

- the LPDU processing time at the link station. 


For the direction of data transmission from the remote to the local link station, LT2" 
indicates the maximum amount of time allowed between receipt of an LPDU requiring an 
acknowledgment and initiation of the transmission of the acknowledging LPDU to insure 
its receipt at the remote link station prior to the expiration of Timer LT1. The value 
of LT2" must be less than the value of LTl. 


Given a value for Timer LT1, the value of Timer LT2" must be no greater than LT1 less: 


- the propagation time across the link connection from the link station 

in the adjacent node; 
= the LPDU processing time at the link station; 

- the time required to transmit the acknowledging LPDU to the link 

station tin the adjacent node; 

- the propagation time across the link connection to the link station 
in the adjacent node; and, 

~- the LPDU processing time at the link station in the adjacent node. 
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K.6.5.4 Maximum Number of LPDU Transmissions - ( LN2 ) 


The maximum number of transmissions and retransmissions of a given LPDU following the 
expiration of Link Reply Timer LT1 is a LLC parameter (LN2) whose value is determined 
by bilateral agreement between adjacent link stations. 


Note: To facilitate throughput enhancement in environments where the quality of 
service exhibited by underlying network services afford adequate data integrity 
support of the retransmission recovery function may be bypassed when the value of LN2 
is equal to one (1). 


K.6.5.5 Maximum Number of Bytes in an IPDU - ( LNi ) 


The maximum permissible number of octets (bytes) in an IPDU 1s an LLC parameter (LNI1) 
which depends upon the maximum length of the information fields transferred across the 
link connection. 


K.6.5.6 Maximum Number of Outstanding IPDUS - ( Lk ) 


The maximum permissible number (Lk) of sequentially numbered IPDUs that link stations 
may have outstanding (i.e., unacknowledged) at any given time is an LLC parameter 
which can never exceed one hundred twenty-seven (127). The value of ‘Lk’ is 
determined by bilateral agreement between adjacent link stations. It 1s recommended 
that 'Lk" be a parameter whose default value can be overridden. 


K.6.5.7 Link Idle Timer - ( LTi } 


The period of time that a link station may allow the link connection to remain in the 
idle state (see "Link Channel States" on page II-K-4) before, initiating a procedure 
to protect against half-open link connections by, transmitting an LRR command LPDU. 


Ee many times greater than LT1, and typically has a value in the order of (CLN2 X 
LT1)72. 


K.7 LPDU FLOW EXAMPLES 


Sample ELLC LPDU flows depicting initial link establishment, initialization, 
information exchange, recoverable call clearing and connection recovery are shown in 
Figure K-10. 
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Figure K-10. ELLC: 
The following notes are keyed to Figure K-10. 
1. Initial Connection Initiation 


Link connection establishment is 


@ ~—6C910) - Initial connection indicator © 
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initiated by the transfer of 
packet, to the network access DCE, with the following parameters in the CUD field: 


e (ed) - Extended LLC protocol indicator © 


Unnumbered Acknowledgement response 


Enhanced Logical Link Control — ELLC 


Sj DCE DCE LSk 
1. o CRQCIC,e,nul_cid) Oo o 7 | re) 
® > $e INC CIC, e,nul_cid) oO 
° 0 Mme > @ 
oO a 0 fe) CAC 
o 7 CCN e< +< 
nl Oo re] 
re) . n°) re) oO 
2. o TDTCSMc) re] re) re) 
RRR > @ 
re) oO oO TDTCUAr) o 
e< e 
o TDTCRRc) oO oO fe) 
@ (Optional) >@ 
re) oO re) TDTCRRr) o 
e< COptional) e 
0 0 o re) 
3. o TDOTCIc,data) 0 ro) oO 
Ga a eee 
0) oO o TDTCIc,data) o 
———— 
o oO re) oO 
re) re) oO re) 
4. o CLI(€cc>,d) oO re) CLiI¢€ce,d) o 
‘——— 9 ° >e 
Ds | CRQCCr,e,nul_cid) ° ° ° 
>+ >e INC(Cr,e,nul_cid) re) 
re) re) ; >e 
o re) | re) CAC 
° CCN e<——————————_-+< 
8 << d : oO oO 
6. o TDTCRRc) o | oO oO 
——————————————————— eC Opti onal) >@ 
o re) oO TDTCRRr) o 
e< COptianal) 
re) re) oO o 
7. o TDTCIc,data) 'e) re) ie) 
e >e 
o o re) TDTCIc,data) o 
e< & 
ve) ° o o 
oO fo) o re) 
8. o CLR(cc,d) ve) re) o 
.————— yf e CLI(cc,d) oO 
o NCC mes > @ 
o< re) Tcc¢ 
re) re) o< 
re) ° o re) 
Legend: 
cc: Clearing Cause code 
cid: Connection Identifier 
Cr: Connection Recovery Indication 
d: Diagnostic code 
e: ELLC protocol identifier 
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iC: Initial Connection indication 
LSC€1) Link Station "i! 
nul: Null 
SM: SABME Unnumbered command 
UA: 


a CALL_REQUEST 
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° (cid) - Connection identifier Coptional) 
2. Link Initialization 


Link initialization is initiated by the transfer of a DIE_DATA packet containing 
an LSABME command LPDU in the user data field and may be terminated either by the 
receipt of an LUA command LPDU or receipt of an LUA command LPDU followed by an 
exchange of DTE_DATA packets containing LRR command and response LPDUs, 
respectively. 


3. Information Exchange 
Information is exchanged between adjacent link stations by the transfer of DATA 
packets or packet sequences with the user data field containing an information 
command LPDU. 

&. Network Initiated Call Clearing 


Network initiated call clearing is signalled by the transfer of unsolicited 
CLEAR_INDICATION packets to both the calling and called link stations containing: 


° (cc) - Cause Codes tn the Clearing Cause field. 
e (dd) - Diagnostic Code in the Diagnostic Code field. 


5. Connection Recovery 
Link connection recovery, following a recoverable network initiated call clearing 


is initiated by the transfer of a CALL_REQUEST packet, to the network access node, 
with the following parameters in the CUD field: 


° (Cr) .- Connection Recovery indication 
e Ce) - Enhanced LLC protocol indicator 
e (cid) - Connection identifier Coptional ) 


6. Link Initialization/Assurance 


Link re-initialization is accomplished by an exchange of LRR command and response 
LPDUs, respectively. 


7. Continue Information Exchange 
Proceeds as in item 3. above. 
8. Connection Termination 


Termination of a link connection is initiated by the transfer of a CLEAR_REQUEST 
packet, to the network access node, containing the following parameters: 


e (cc) - Clearing Cause Code; and, 


® (d) - Diagnostic Code. 


K.8 LINK STATION STATES AND ACTIONS 


K.8.1 Chart Description 


Operation of the ELLC protocol for link stations is formalized by the charts contained 
in "Link Station States and Actions” on page II-K-32 for the link connection states 
defined in "ELLC STATE DESCRIPTIONS” on page II-K-26. Action(€s) taken by link 
station(s) as a result of particular stimuli are shown at the intersection of the 
various link connection states and the stimulus. ELLC link connection states include 
the predicate conditions defined in “PREDICATES™ on page II-K-27 and the state 
variables defined in "State Variables" on page II-K-28, either or both of which are 
indicated under the heading(s) 'P: V:' (when appropraite) in the charts in "Link: 
Station States and Actions" on page IJI-K-32. ELLC stimuli include the events as well 
as the command and response LPDUs defined in "ELLC Stimuli™ on page II-K-28. 


information contained at these intersections specify the action(s) taken (denoted by) 
two uppercase letters 'LL'), the basic procedure executed (denoted by the small . 
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letters "bp" concatenated with an uppercase letter 'L'), the PDUCs) transferred Cif 
any), signified by the protocol data unit identifier enclosed in brackets with any 
required parameters [PDU_id(pl,..,pnJ)J] and the new state of the link connection to be 
entered (Cif any). 


- The PDU transferred, [PDU], may be any of the LLC command or response LPDUs listed in 


"Commands sent and Receivec™ on page II-K-29 and "Responses Sent and Received" on page 
II-K-29 and a small letter ‘'c’" or 'r’" may be appended signifying command or response, 
respectively; or the LPDU indicated by the PDU output scheduling algorithm signified 
by an undefined protocol machine [CPDU_Out_UPM]. XPo, TPo and LPo signify the output 
PDU indicated by execution of the basic procedures X, T and lL» respectively. 
Additional appendages that specify the value of the P-bit for command LPDUs and the | 
F-bit for response LPDUs when necessary, include: 


0 - signifying a P/F-bit value of '0'; 

1 - signifying a P/F-bit value of "1'; 

vw - signifying a P/F-bit value equal to the value of the variable, VF5 and 

' = signifying an F-bit value equal to the value of the P-bit in the received 
command LPDU to which it responds. 


In the event the PDU transferred causes a packet level clearing or resetting of the 
associated virtual circuit, an appropriate diagnostic code is included (see Appendix F 
for DTE Generated Diagnostic codes used when the virtual circuit for SNA-to-SNA 
connections are cleared, reset or restarted). When no [PDU] is indicated, nothing is 
transferred across the link connection to the link station in the adjacent node as the 
result of that particular stimulus. 


Applicable ELLC link connection state transitions are specified under the heading New 
State when the link connection is to be placed in a different state following’ the 
specified action(s) and/or PDU transfer. Link connections remain in the current state 
when no new state to be entered is specified at a particular intersection. 


Alternative procedures, denoted by lower case letters 'l’ or the word ‘or’ under the 
"ALT' heading, are specified where appropriate. 


References to clarifying notes (denoted by '#n' Cwhere 'n' is a decimal diait) under 
the ‘ALT" heading) are also provided at certain intersections, where deemed necessary, 
to explain extenuating circumstances considered essential to proper operation of the 
protocol, including: 


1. When an exchange of link station identification information is not required prior 
to link set-up. 


2. The virtual call Cswitched virtual circuit) supporting the link connection is 
cleared (e.g., CLEAR _REQUEST or CLEAR_INDICATION) the underlying virtual circuit 
is terminated and the link connection placed in the INOPERATIVE state. 


The sample sequences shown in Figure K-10 on page II-K-24 represent one example of how 
the tables may be used. 


K.8.1.1 ELLC STATE DESCRIPTIONS 


INOPERATIVE:. The link station, not having resources allocated sufficient to support | 
link connection, is non-functional and reacts positively only to link activation | 
stimulus as specified in "INOPERATIVE State” on page II-K-32 


LINK_CLOSED: The link station, having sufficient resources to support link connection 
allocated, reacts to stimuli as specified in "LINK_CLOSED State" on page II-K-33 when 
authorized and prepared to support link initialization. 


LINK OPENING: Link stations ene initiated the link set-up procedure, by 
transferring an SABME command LPDU across the link connection, react to stimuli as 
specified in “LINK_OPENING State™ on page II-K-35 pending receipt of link set-up 
confirmation CUA response LPDU) from the link station in the adjacent node. 7 


LINK _CLOSING: Link stations having initiated the link disconnection procedure, by 


transferring a DISC command LPDU across the Link connection, react to stimuli as. 
specified in:<-- Heading id 'closg’ unknown --. 
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LINK_OPENED: Link stations having completed the link set-up procedure react to 
stimuli as specified in "LINK_OPENED State" on page II-K-39 in the absence of error or 
exception condition(s) effecting the associated link connection. 


CHECKPOINTING: Link stations having transferred an S-format command LPDU with 'P=1' 
across the link as a result of the expiration of the link reply timeout, Timer LTl, on 
the associated link connection react to stimuli as specified in "CHECKPOINTING State" 
on page II-K-42. 


LINK_RESETING: Link stations having received an SABME command LPDU from the link 
station in the adjacent node, initiating the link resetting procedure, react to 
stimuli as specified in "LINK_RESETING State” on page II-K-48 until the resetting 
procedure is completed by the transfer of either a UA or DM response LPDU as directed 
by a higher level function. 


LINK_RECOVERY: Link stations having received a FRMR- response LPDU from, or 
transferred a FRMR response to, the link station in the adjacent node react to stimuli 


as specified in "LINK_RECOVERY State” on page IJI-K-49 until a resetting procedure is 
completed for the link. 


K.8.1.2 PREDICATES 


ELLC predicate conditions include: 


: which signifies general condition(s) for the link connection and may take on the 
values: 


1. "Nul’ — signifying that no outstanding exceptional general conditions exists for 
the link connection. 


2. YRIN® — signifying that an out-of-sequence IPDU has resulted in the transfer of an 
REJ command or response LPDU to the link station in the adjacent node. 


Pb Busy: Signifies condition(s) for the link relative to resource constraints that 
temporarily prevent acceptance of I~format LPDU(s): 


e "B’ by both the local link station and its communicating partner in the adjacent 
node; 

° 'L' by the local link station; 

® "N’ by neither the local nor its communicating partner in the adjacent node; or, 


° "R' by the link station in the adjacent node. 


Pc_Pending Command Identifies the pending command LPDU when a command transmission is 
awaiting completion of a checkpointing cycle, and may take on the values: 


e "D' signifying a Disconnect command; 

e "R’ signifying a Receive_Ready command; 

° "T’ signifying a Test command; 

e "X’ signifying an Exchange_Identification; or 


e "N’ signifying that no command LPDU is pending. 


Pr_Recovery.Status: 


e *"Nul’ signifying no recovery procedure in process; 

e "L' signifying recovery due to a locally detected PDU Rejection condition in 
process; or, 

e meer signifying recovery due to a remotely detected PDU_Rejection condition in 
process. 


Pt_TEST.Status: 
e "Nul!’ signifying that no TEST of the link connection is in process; 


° 'I' signifying that an incoming TEST response LPDU from the link station in the. 
adjacent node is pending; 
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e 'g* signifying that an outgoing TEST response LPDU to the link station itn the 
. adjacent node 1s pending; 


e 710" signifying that an incoming TEST response LPDU from and an outgoing TEST 
| response LPDU to the link station in the adjacent node are both pending. - 


Px XID.Status: 


e "Nul*® signifying that no exchange of identification information (XID) is in 
process; | 


® ee signifying that an incoming XID response LPDU from the link station in the 
adjacent node 15 pending; 


® "90? signifying that an outgoing XID response LPDU to the link station in the 
adjacent node is pending; | | 


® "IO" signifying that an incoming XID response LPDU from and an outgoing XID 
response LPDU to the link station in the adjacent node are both pending. 


K.8.1.3 State Variables 


ELLC state variables include: 


Va ~ Acknowledged LPDU: containing the last Nr value received, or "0" immediately 
following completion of the link set-up procedure; 


Vf ~ Final Bit Value: containing the value for a final bit pending transmission (e.g., 
associated P-bit value received). 


Vi ~ Initialization Status: Signifies link initialization progress and may take on 
the values: 


e 'L* signifying locally initiated link set-up; 

° "R' signifying remotely initiated link set-up; 

e "B’ signifying locally and remotely initiated link set-up; 

° "P*® signifying initialization confirmation pending; or, 

"Nul® signifying initialization completed/not started. 

Vr — Next IPDU In: denoting the sequence number (Ns) of the next in- sequence I-format 
a to be received across the link connection from the link station in the adjacent 
Vs — Next IPDU Out: denoting the sequence number (Ns) of the next in-sequence I-format 


~PDU to be transferred across the link connection to the link station in the adjacent 
node. 


K.8.1.4 ELLC Stimuli 


ELLC pretocol stimuli include the events, commands and responses described in the 
following paragraphs. 


Events 


° L3RDY — PACKET_LAYER (Level 3) READY: representing a signal from the X.25 Packet 
Layer (level 3) that the underlying virtual circuit, in the READY (Cp4@ or dl) 
state, is prepared to support a link connection. 


° LSTRT -— LINK_START: representing a higher level stimulus to establish a link 
connection to a communicating link station in the adjacent node. 


® LSTOP -— LINK_STOP: repesenting a higher level stimulus to terminate the link 
connection to the communicating link station in the adjacent node. 
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L3NOP — LEVEL_3_INOPERATIVE: representing a signal from the X.25 Packet Layer 
(level 3) that the underlying virtual circuit, in the INOPERATIVE state, is no 
longer capable of supporting a link connection. 


ELBSY -— ENTER_LOCAL_BUSY: representing a signal from the DLC.X25 Manager 
informing the link station of a local resource constraint that temporarily 
prohibits the continued acceptance of I-format LPDUs. 


XLBSY — EXIT_LOCAL_BUSY: representing a signal from the DLC.X25_Manager informing 
the link station of the removal of an existing local resource constraint. 


ELPDU — ERRONEOUS _ LLC _PROTOCOL_DATA_UNIT: representing receipt of an erroneous 
LPDU Ce.e., one containing an unidentifiable LLC command or response, etc.) on the 
link connection. 


XCHID _ EXHCANGE_IDENTIFICATION: representing a higher level 
request/authorization to transfer LLC link station identification information. 


LTEST — LINK_TEST: representing a higher level request/authorization to transfer 
LLC link test data. 


SDATA -— SEND_DATA: representing a higher level request for the transfer of user 
data to the link station in the adjacent node. 


ELTIX — ELLC_LINK_REPLY_TIMEOUT_EXPIRATION: representing expiration of the LLC 
link reply timeout, Timer LTl. 


ELTiX —- ELLC_LINK_IDLE_TIMEOUT_EXPIRATION: representing expiration of LLC link 
query timeout, Timer LTi. 


Commands Sent and Received 


LI - I-format LPDU: representing a DATA packet or packet sequence containing an 
I-format LPDU in the user data field(s). 


LSM — LLC_SET_MODE C(LSABME): representing a DATA packet containing a Set_Mode 
command LPDU (LSM) in the user data field. 


LDC — LLC_DISCONNECT C(LDISC): representing a DATA packet containing a Disconnect 
command LPDU (LDC) in the user data field. 


LXC — LLC_EXCHANGE_IDENTIFICATION: representing a DATA packet or packet sequence 
containing an Exchange_Identification command LPDU (C(LXC) in the user data 
field(s). 


iTC ~- LLC_LOGICAL_LINK_TEST: representing a DATA packet or packet sequence 
containing a Link_Test command LPDU (LTC) in the user data field(s). 


LRR —- LLC_RECEIVE_READY: representing a DATA packet containing a Receive_Ready 
command LPDU CLRR) in the user data field. 


Resporses Sent and Received 


LDM - LLC_DISCONNECTED_MODE: representing a DATA packet containing a 
Disconnected_Mode response LPDU (LDM) in the user data field. 


LPR — LLC_PDU_REJECT: representing a DATA packet containing a PDU_Reject response 
LPDU CLPR) in the user data field. 


LUA -— LLC_UNNUMBERED_ ACKNOWLEDGE: representing a DATA packet containing an 
Unnumbered_Acknowledge response LPDU CLUA) in the user data field. 


LXR —- LLC_EXCHANGE_IDENTIFICATION: representing a DATA packet or packet sequence 
containing an  Exchange_Identification response LPDU (LXID), including link 
station identification information, in the user data field(s). 


LTR ~- LLC_TEST: representing a DATA packet or packet sequence containing a 
Link Test response LPDU (LTR), including test data, in the user data field(s). 


LRR - RECEIVE_READY: representing a DATA packet containing a Receive_Ready 
response LPDU (LRR) in the user data field. 
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K.8.1.5 BASIC PROCEDURES 


Basic procedures defined for ELLC link stations, specified at the intersection of a | 
state/condition/option and a stimulus, denoted by a small letter ‘bp' concatenated 
with a capital letter "L‘' (bpl), include: 


bpA ~ AcknonNledgment: Process the received Nr value according to the procedure 
specified by CHART_A in "Acknowledgment" on page II-K-50 and if Va<Nr<Vs : Va=Nr, RT1; 
Va<Nr=Vs : Va=Nr, TT1, ITi; ELSE ; NS. 


bepL ~ Limit: Perform the procedure specified by CHART_L in "Limit™ on page II-K-51 
which increments the Cre)-transmission count 'Ct' by one, then if Ct=N2 : report the 
failing procedure to, and await further direction from, a higher level of SNA; Else : 
retry the indicated protocol procedure. 


bPpR ~ Rejection: Process the received REJECT command/response LPDU according to the 
procedure specified by CHART_R in “Rejection” on page II-K-51 and if Va<Nr<Vs 
Va=Vs=Nr, RT1; Va<Nr=Vs : Va=Vs=Nr, TT1, ITis ELSE : Vs=Nr. 


bpT ~ TEST: Perform the procedure specified by CHART_T in "Link Test™ on page II-K-5l 
with the result that if Pt=Nul : Pt=Ip, TTi, RT1, Ct="'0"', CLTC4] > CHECKPOINTING; 
Pt=Rp : IH, Pt=Nul, CLTRCF=Vf,id)]; Pt=IRp : IH, Pt=Ip, CLTRCF=Vf,id)]; Else : LE. 


bPpX —~ EXCHANGE IDENTIFICATION: Perform the procedure specified by CHART_X in 
"Exchange Identification" on page II-K-51 with the result that 1f Px=Nul : Px=Ip, TTi, 
RTi, Ct='0", [CLXC!] > CHECKPOINTING; Px=Rp : IH, Px=Nul, ULXRCFRVF,id)]; Px=IRp : IH, 
Px=Ip, [TLXRCF =Vf,id)J; Else: LE. 


K.8.1.6 Actions 


Actions taken by ELLC link stations, denoted = at the intersection of a 
state/condition/option and a stimulus, are identified by two capital letters 'LL* 
which are defined as follows: 


DB - Discard BTU: Discard the contents of the information field of the received PDU 
and take no further action as a result of its receipt. 


DL - Disable Link: Destroy the link connection, releasing the Access Channel and 
Media Access Port associated with the link appearance. 


EL - Enable Link: Establish a link connection by associating a specific Access 
Channel and Media Access Port as required to create a link appearance. 


FB - Forward BTU: Forward the received Basic Transmission Unit to the higher level 
using protocol entity. 


IH - Inform Higher Layers: Informa higher layer of SNA of the occurrence via internal 
signalling mechanisms. 


IP - Ignore Protocol Data Unit: Take no action and ignore the received protocol data 
unit in its entirety. 


ITi - Initiate Query Timer, LTi: Initiate a logical link timeout for the duration of 
Query Timer, LTi. 


LE - Local Procedure Error: Representing an internal signalling error or illogical 
protocol sequence on the part of the ELLC link station that may be either’ ignored or 
reported to a higher layer of SNA for analysis. 


NA - Wot Applicable: Identifies events/actions/responses that cannot occur for a 
given state/condition/alternative. 


NS - No Specific Action: No specific action is required by the ELLC link station 
protocol. 


QL - Queue LPDU: Place the output BTU in the information field of an Information LPDU, 


place the LPDU on the outbound queue for the associated logical link, and pass control 
to the PDU_Out_UPM. 
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RE - Remote Procedure Error: Representing a protocol procedure error on the part of 
the ELLC link station in the adjacent node that may be either ignored or reported to a 
higher layer of SNA for future analysis. 


RS - Report Status: Report the current status of the ELLC link station to a higher 
level of SNA. 


SL - Set-Up Link: Initiate the link set-up procedure described in §-4.5.4.1. 


Te - Terminate Contact: Terminate the SNA_CONTACT phase and signal CONTACTED to a 
higher level of SNA. 


TL - Terminate Link: Terminate the Link initialization procedure and transfer an 
unsolicited DISCONNECTED_MODE response to inform the link station in the adjacent 
node. 


TYTi1 - Terminate Timer LTi: Terminate LLC Query Timer, LTi. 
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CHART 1-E: 


CHART 1-1: 


CHART 1-S: 


CHART 1-U: 
Stimuli P: 


LPR 
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K.8.2 Link Station States and Actions 


K.8.2.1 INOPERATIVE State 


EVENTS in INOPERATIVE State 


I-—Format LPDUs in INOPERATIVE State 


S-format LPDUs in INOPERATIVE State 


U-format LPDUs in INOPERATIVE State 
V: ALT! Action(Cs) 
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K.8.2.2 LINK_CLOSED State 


CHART 2-E: EVENTS in LINK_CLOSED State 


Stimuli P: V: ALT] Action(s) C[PDU Transfers] New State 


LSTRT ct+tttxNul+ 
iNul SL, Vi=L, Ct=0, TTi, RT1l CLSM!]} LINK_OPENING 


iR SL, Vi=P, TT1, ITi LINK_OPENING 
ELSE 


LSTOP TL, Vi=Nul, TT1, ITi CLDM? ] 


[XPo'] 


Ct<LN2+ 
xI [IO 


tI] 10 
ELSE 
ELTiX Nul 


CHART 2-I: I-Format LPDUs in LINK_CLOSED State 


CHART 2-S: S-format LPDUsS in LINK_CLOSED State 


Action(s) [PDU Transfers] New State 
Pireiunenimiee se OOS—S—SSCSiS 
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CHART 2-U: U-format LPDUs in Received LINK_CLOSED State 
| Nul+iNul[R | IH, ViER, VfEP, IT: | —_ nee 
ip —s«d|sTH, Pc=Pt=Px=Va=Vf=Vs=0, ITi  ELUAM 


éLSE 


Stimuli P: V: 


Lxc IH, Px=0, Vf=P Lo 
LXR°]2  xI IH, Px=Nul, TTL : 
xI0 | | | 
ELSE IP_(RE) 
LTC IH, Pt=0, Vf=P ae 
IH, Pt=Nul, TTl | | | 
neo ulated nladialaliababatie 
IP(RED ss BO 
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K.8.2.3 LINK_OPENING State 


CHART 3-E: EVENTS in LINK_OPENING State 7 


Stimuli P: V: ALT] Action(s) CPDU Transfers] New State 


Vi=Nul, TT1, ITi CLDM° J LINK_CLOSED 
DL INOPERATIVE 


CHART 3-E: EVENTS in LINK_OPENING State (Continued) 


Stimuli P: V: ALT] Action(s) [PDU Transfers) New State 


CHART 3-I: I-Format LPDUs in LINK_OPENING State | 
Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 


IH, Vi=Nul, FB, RTI CLRRr®] LINK_OPENED 


C[LRRr?] LINK_OPENED 
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CHART 3-S: S-format LPDUs in LINK_OPENING State 
Stimuli P: V: ALT] Action(s) ee [PDU Transfers] New State | — 
LRRILNRILRJo® TP 


LRRCO)| 
LRJCO)c! —oiR 


ELSE 


IH, Pb=Nul, Vi=Nul, RTi CLRRr?] LINK_OPENED | : 


bead me Led enm ‘on extn == 


IH, Pb=R, Vi=Nul, RTi CLRRr?] 


LNRCO)c? LINK_OPENED | 


ELSE 
LRRILNRILRJr? "2 


CHART 3-U: U-format LPDUs in LINK_OPENING State | 


Stimuli P: V ALT] Action(Cs) [PDU Transfers] New State — 


Vi=R, TT1, ITi CLUA'] 


TH, Vi=Nul, TT1, ITi CLDM'] LINK_CLOSED 


LUA? IH, Pco=Pt=Px=Va=Vf=Vi=Vr=Vs=Nul, TTi;, 
RTi C[LRRc!]} CHECKPOINTING 
LDM?! IH, Vi=Nul, TT1, ITi LINK CLOSED 


call Le 
o;ron 
oO}; 3 


~- 
*< 
oO 


LDM|LUA® 


IP 
LPR | IP_CRE) 7 


IP_CRE) | | 
LXR | IP_CRE) 


| ream 
~ 
O 


r 
—{ 
A 
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K.8.2.% LINK_CLOSING State 


crest 


co 
m 


rm 
m 


Cc 
m 


CC 
mi 


XCHID LE 


SDATA 
ELPDU 
ELT1ixX 
ELTiX 


r 
m 


CHART 4-I: I-Format LPDUs in LINK_CLOSING State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 
LI rrr ere 


CHART 4&-S: S-format LPDUs in LINK_CLOSING State 
Stimuli P: V: ALT 
LRRILNRILRJ 


Action(s) C[PDU Transfers] New State 
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CHART 4-U: U-format LPDUs in LINK_CLOSING State 


Action(s) | C[PDU Transfers] 


LXC 


IP_CRE) | 


a 
a 


IP_CRE) | | 
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K.8.2.5 LINK_OPENED State 


CHART 5-E: EVENTS in LINK_OPENED State 


a 
a 


bL|B 
RJN+[bR 
ELSE 
bL 
bB 
RJN+bL 
RJN+bB 
ELSE 


Pb=Nul, RT1, Ct=0 ~ ELRRe?!] 


Pb=R, RT1, Ct=0 CLRRc!] 


Pb=Nul, TTi, ITl, Ct=0 


Pb=R, TTi>» RTl, Ct=0 ILRRc?] 


CHECKPOINTING 
CHECKPOINTING 
CHECKPOINTING 
CHECKPOINTING 


Px=I, TTi, RT1, Ct=0 


IH, Px=Nul 


CHECKPOINTING 


Pt=I, TTi, RT1, Ct=0 


TH, Pt=Nul 


CHECKPOINTING 


SDATA QL [PDU_Out_UPM] Ld 
ELPDU IH_(RE), TTl, ITi> Pre [LPR°]| LINK RECOVERY 


ELT1X RJN+[bR RT1, Ct=0 CLRRc?]| CHECKPOINTING 
RJN+bL [.B RT1, Ct=0 CHECKPOINTING 


bL |B IT1, Ct=0 CHECKPOINTING 
ELSE IT1, Ct=0 CLRRc?]} CHECKPOINTING 
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CHART 5- 


I: I-Format LDPUs in LINK_OPENED State 


Stimuli P: VW: ALT| Action(s) [PDU Transfers] | New State | 


Llic|r® RJN bpA, FB, P=Nul | LPDU_Out_UPM] 
: we”) fee eee ee 
or té‘(i‘mU CARY DBO! OT  ELRR FO? 

| RJN+bL1B | bpA, DB, P=Nul—™S” ~ ELNRr® 
-—RJN+bR bpA, FB, P=Nul—“‘é été; CCERRYO 

| ELSE §—S*«(|«»dbpAy *FBOti‘(<‘(‘C(C!;é‘OCO*;*#C#CNPDUL OUR _UPM 


LIlic! RJN FB, P=Nul 
bLIB.=Ss—i(<aésédrY«é py DBO tt*~<i:=isi‘“‘<‘i;é‘;*~™~CSCARNR 
RJN+bL |B 
RJN+bR 

ELSE 


DB, P=Nul 


bpA, FB, P=Nul CLRRr?] 


LINK_RECOVERY 


= 
7 
[med 


LIec|r® RJN,bLIB 
RJN+bL |B 
bR 
RJN+bR 
ELSE 
RJN,»bLIB 
RJN+bL |B 
bR 
RJN+bR 
ELSE 


LIer? ELSE : IH_(RE), Va=Vs=Nr, TT1, ITi, Pr=L CLPR°]} LINK_RECOVERY 


LRRc[r® RJN+bL bpA 
be ti‘<i‘i‘i‘ edt CACO!” ne  “eRDU Dut UPM 
RUN BB beA, Pb=L)—s—<“<i‘CéSC*‘CR OUP] 
ELSE bpA, Pb=Nul ee [PDU_Out_UPM] 


LIec? 


LRRc? RJN|bL 
RJN+[bB 
ELSE 
RJN+bL 
RJN+bR 


~~ bpA, Pb=L CLNRr?J 


bpA, Pb=Nul | [LRRr?] 
TH_CRE), Va=Nr, TTL, IT, Pret CLPR°] 


LRRr? LINK _RECOVERY 


LINK_RECOVERY 


IH_(RE), Va=Vs=Nr, TT1, ITi, Pr=L LLPR°] 
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ELSE 
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CHART 5-S: S-format LPDUs in LINK_OPENED State (Continued) 


Stimuli P: V: ALT! Action(Cs) [PDU Transfers] New State 


LNRc|r® RJN+bL bpA, Pb=B 
bNul bpA, Pb=R ies: [LRRr°] 
bL bpA, Pb=B ees CLNRr®] 
ELSE bpA ei ial 


bpA, Pb=R CLRRr?] 


LINK_RECOVERY 


IH_CRE), Pb=R, Va=Vs=Nr, TTl, ITi, Pre 
CLPR°]| 


LINK_RECOVERY 
RJN| bL | 
bB 
ELSE 
RUN 
RJN+|bL 
RJN+[bB 
ELSE 
bB 
RJN+bR 


bpR, Pb=L, Pr=L C[LPR°] 


LINK_RECOVERY 


LINK_RECOVERY 
LINK_RECOVERY 


IH_(RE), Va=Vs=Nr, TT1, ITi, Pr=L CLPR®°] 


ELSE 


CHART 5-U: U-format LPDUs in LINK_OPENED State 

Stimuli P: V: ALT| Action(s) [PDU Transfers] 
IH, Vi=R, Vf=P, TTL, ITi LINK_RESETING 
IH, TTl, ITi [LUA'] 


LINK_CLOSED 
IH_CRE), TT1, ITi, Pr=t CLPR°J| LINK_RECOVERY 
TH, TTi, IT1 


LINK_CLOSED © 
IH, TTl, ITi, Ct=0, 


IH, Px=0, Vf=P 
IH_(RE), Px=Nul, TT1, ITi, Pr=R  CLPR°]| LINK_RECOVERY | 
IH, Pt=0, Vf=P Po 
IH_(RE), Pt=Nul, TT1, ITi, Pr=R  CLPR°J| LINK RECOVERY | 
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 K.8. e. 6 Cc 


HECKPOINTING State 


CHART 6- 


Stimuli P: V: ALT 


EVENTS in CHECKPOINTING State 
Action(s) 


E: 


CPDU Transfers] 


New State 


cNul | 
— RUJN+tcR | ) 

ELSE | | 

RJN+[cR = = 

RJN+|bR Pb=B, Pc=Nul , 

bL|B | 

ELSE | | 

ms ; aie as 
| XCHID  cNul+ 

xNul 

x0 Px=Nul CLXR"] 

x10 IH, Px=I | [LXR™] 
IH, Pt=Nul [LTR] 
IH, Pt=I CLTR"] 


SDATA [PDU_Out_UPM] as 
ELPDU | IH_(RE), TTl, ITi, Pre [LPR°J| LINK RECOVERY 
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t+x#0 | Ct=Cttl 
Ct=LN2 IH, IT1, ITi LINK_CLOSED 


t+xNul 


x0 | IO+ 
Ct<LN2 


tO|[IO+ 
Ct<LN2 
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CHART 6-I: 


LIic|r® RJNtcR+t 
aNr<Vs 


<NrsVs 


cR+ 
aNr<Vs 


<NrsVs 
bLtaNr<Vs 
<NrsVs 


RJN|RJN+bL 
aNr<Vs 


<NrsVs 


ELSE 
aNr<Vs 


<NrsVs _ 


RJNt+cR+ 
aNr<Vs 


a<Nrsvs 


cR+ 
alir<Vs 


a<NrsVs 
bLt+taNr<Vs 
a<NrsVs 


RJN|RJNtbL 
aNr<Vs 


LIec|r® cRtaNr<Vs 
a<NrsVs 
RJN+cRt+ 
aNr<Vs 
a<Nrsvs 
bLt+aNr<Vs 
a<NrsVs 


RJN[RJN+bL+ 
aNr<Vs 


aNr<Vs 


a<NrsVs 
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I-Format LPDUs in CHECKPOINTING State 


Stimuli Ps: V: ALT] Action(€s) 


CPDU Transfers] 
P=Pc=Nul, FB CLRRr°J 
P=Pc=Nul, Va=Nr, FBO” CLRRro] 
Pe=Nul, FB CLRRr®] 
Pe=Nul, Va=Nr, FBO [LRRr°] 
DBO CLNRr°] 
VaeNr, DBO —S CLNRr° 3 
P=Nul, FB ns [LRRr°] 
Va=Nr, P=Nul, FBO” CLRRr°] 
rR ee [LRRr°] 
Va=Nr, FB ee [LRRr°] 
P=Pc=Nul, FB C[LRRr?] 
P=Pc=Nul, Va=Nr, FBO” CLRRr?] 
Pe=Nul, FB CLRRr?] 
Pe=Nul, Va=Nr, FBO” LLRRe?} 
Bo CLNR?] 
Va=Nr, DBO CLNRr?] 
P=Nul,y FBO CLRRr?] 
Va=Nr, P=Nul, FBO” [LRRr?} 


Pe=Nul ? 
Pc=Nul, 
Pc=Nul, 


DB, P=RJN 
Va=Nr, DB, 
DB, P=RJN 
Pc=Nul, Va=Nr, DB, 
DB, P=RJN 

Va=Nr, 


P=RJN 


P=RJN 


DB, P=RJN 


DB, P=RJN 
Va=Nr, DB, 


P=RJN CLRJr?] 
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CHART 6-I: I-Format LPDUs in CHECKPOINTING State (Continued) 


Stimuli P: V: ALT| Actions) | CPDU Transfers] New State 


LIec? cRtaNr<Vs = DB, P=RJN 


a<NrsVs = Va=Nr, DB, P=RJN 
RJN+cR+t 

aNr<Vs = DB, P=RJN 

a<NrsVs =Nul, Va=Nr, DB, P=RJN 
bLtaNr<Vs DB, P=RJN 

a<NrsVs DB, P=RJN 
RJN+ 

aNr<Vs 

a<NrsVs 


RJN+bL+ 
aNr<Vs 


aNr<Vs 


a<NrsVs Va=Nr, DB, P=RJN 
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CHART 6-S: S-format LPDUs in CHECKPOINTING State 


Stimuli P: V: ALT} Action(s) [PDU Transfers] New State 


LRRc|[r® cR = 
RJN+|bL+ : 
‘aNr<Vs 
a<Nrsvs = 
RJNt+bR+cR+ 
IH, Pb=Nul, Va=Nr 
a<NrsVs | 
| -_ 


RJN+|bL+ 
aNr<Vs CLNRr?] 


a<Nri<vs 
RJN+bRt+cRt 
aNr<Vs 


a<NrsVs | IH, Pb=Nul, Va=Nr 
E 


aNr<Vs 


ss ccncaenonicaal 
LNRc|r® bNultcR | = 

bL+cR = 
RJNtcR b= = 
RJN+bLt 

aNr<Vs 

aNr<Vs 

a<Nrsvs = 


bNul+cR 3 = C[LRRr! ] 


bLt+cR 
RJNt+bL + 
aNr<Vs 


a<NrsVs 
RJN|RJNtcRt 

aNr<Vs 

a<Nrsvs 


RJNt+bR+cRt 
aNr<Vs 


aNr<V¥s 


a<NrsVs = CLRRr? J 
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CHART 6-S: S—format LPDUs in CHECKPOINTING State (Continued) | _ 
Stimuli P: V: ALT| Action(s) [PDU Transfers] New State | 


LRJc|[r® cRtRJN+bL 


bLt+taNr<Vs 


a<NrsVs 
RINtbRtcRt F--- e-em mem mm Mm em Mm em em em er er eK ee 
aNr<Vs 


IH, Pb=Nul, Va=Nr 


_ a eee lUe le en =e oe GP S&S FE fw we g=eT G@== Gwe eT = Gum 


aNr<Vs 


a<NrsVs 


cRtaNR<Vs CLRRr?] 
aNR<Vs = 

RJN+bL = 

bLtaNr<Vs 
a<Nrsvs 4= 

RJNt+cRt --—- eee ee ee er eK eK ee eK eK ee | 
aNr<Vs5 
a<NrsVs = 

RINtbRtcRt+ F-—-— e-em me me em em me em em em eK er Ke me eK eK eK 
aNr<Vs } = 
a<NrsVs IH, Pb=Nul, Va=N 

FLSE -F-Fe eee er eee ere ee Me Me ee Ke Ke HK 
aNr<Vs 
a<NrsVs 
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CHART 6—-U: U-format LPDUs in CHECKPOINTING State 
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Stimuli P:- V: ALT! Action(s) ([PDU Transfers] New State 


IH, Vi=R, Vf=P, TT1, ITi 
IH, TT1, ITi 


IH_CRE), TT1, ITi, Pr=c 


IH, TTl1, ITi, Ct=0, Pr=R 
IH, Vf=P, Px=R 


Px 


LXR°}? > cNul|R+t 
xNul [0 IH_CRE), TT1, ITi, 
xI IH, Px=Nul, RT1 
xI0 IH, Px=0, RT1l 
Pc=Nul, TTi, RT1, Ct=0 
Pe=Nul, Px=I, TTi, RT1, Ct=0 


Pe=Nul, Pt=I, TTI, RT1, Ct=0 


LTC IH, Vf=P, Pt=0 
LTR° [2 cNullR+ 
aoe IH_CRE), TT1, ITi, Pret 


TH, Pt=Nul, RT1 
tI0 TH, Pt=0, RT1 


Pc=Nul, Px=I, TTi, RT1, Ct=0 
Pe=Nul, Pt=I, TTI, RT1, Ct=0 
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LINK_RESETING 
CLUA'] LINK_CLOSED 
CLPR°J}| LINK_RECOVERY 
LINK_CLOSED 
LINK _RECOVERY 


CLPR°]] LINK_RECOVERY 
CLRRc!] 
[LRRc? ] 


LINK_CLOSING 


[LTC! (data) ] 


CLPR°]} LINK _RECOVERY 
C[LRRc?] 
[LRRc!] 


LINK_CLOSING 


[LTCC data) ] 
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K.8.2.7 LINK_RESETING State 


CHART 7-E: EVENTS in LINK_RESETING State 


L3RDY . LE 
LINK_OPENING 
ViENUL, TTL, IT?” [LDM°]| LINK_CLOSED 


ELBSY bNUL 


XCHID 
LTEST 


IH_(RE), TT1, ITi, Pret [LPR°J| LINK_RECOVERY 


CHART 7-I: I-Format LPDUs in LINK_RESETING State | 
LIic 

LIec 

LIliler 


ae ga 
mem 


CHART 7-S: S-format LPDUs in LINK_RESETING State | 


Stimuli P: V: ALT! Action(s) CPDU Transfers] New State 
meiuniuns pe OSC—SsSsE~*id 
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CHART 7-U: U-format LPDUs in LINK_RESETING State 


P: V: ALT] Action(s) [PDU Transfers] New State 
IH, Vi=Nul, TT1, ITi [LUA']} LINK _CLOSED 


IH, Wi=Nul, TT1, ITi LINK_CLOSED 
IH, Vi=NUL, TT1, ITi, Ct=0, = LINK_RECOVERY 


K.8.2.8 LINK_RECOVERY State 


CHART 8-E: EVENTS in LINK_RECOVERY State 


: 
ViEL, TTi, IT1, Ct=0 [LSM? 3 
TTi, IT1, Ct=0 [LDC?] 
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CHART 8-I: I-Format LPDUs tn LINK_RECOVERY State 
Stimuli P: Vs ALT] Action(s) | [PDU Transfers] New State 
DB [LPR'(Vs,Vr,v)]| ‘LINK CLOSED 


CHART 8-S: S-format LPDUs in LINK_RECOVERY State 
Stimuli P: V: ALT 
LRR|LNRILRJ 


Action(s) CPDU Transfers] New State 


CHART 8-U: U-format LPDUs in LINK_RECOVERY State 


Stimuli P: Vs: ALTI Action(s) [PDU Transfers] | New State 
LSM TH, Pr=Nul, Vi=R, Vf=P, ITI LINK_RESETING © 
LDC JH, Trl, ITi [LUA'] LINK_CLOSED 


Cc 
oni 
> 


LDM TH, TTl, IT LINK_CLOSED 
LPR IH, Pr=R, TT1;, ITi 
LXC 


| me 
4 
© 


K.8.3 Basic Procedure Definitions 
K.8.3.1 Acknowledgment 


CHART A: Procedure for the ELLC Acknowledgment Processing 


Stimuli P: V: ALT] Action(s) [Frame Transfers] New State 


a<Nr<Vs = 
Va=Nr, TT1, ITi 
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K.8.3.2 Limit 


CHART L: Procedure for the ELLC Limit Processing 


Stimuli P: V: ALT] Action(s) CFrame Transfers] New State 


| Ct='"Ctt1" then 
Ct=LN2 IH, TT1, ITi 


ELSE 


K.8.3.3 Rejection 


CHART R: Procedure for the ELLC Rejection Processing 


Stimuli P: V: ALT] Action(s) [Frame Transfers] New State 


a<Nr<Vs 


Va=Vs=Nr, TT1, ITI 


K.8.3.% Link Test 


CHART T: Procedure for the Link_Test Processing 
ctxttNul Pt=I, TTi, RT1, Ct=0 CHECKPOINTING 
c+xNul+t+to TH, Pt=Nul 
ctxNul+tI0 
ELSE 


Stimuli P: Vs: ALT} Action(s) 


ct+tttxNul Px=I, TTi, RT1, Ct=0 
ct+ttNul+x0 IH, Px=Nul 


ct+tNultxI0 IH, Px=I 
ELSE 


NNNNMMNMNNMNNMNNNMNNNNNNMNNMNNMNNNNMNMNMNNNNNNNNNNNNNNNNNNANNNNNANANNNMNNANNNNNN 
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